[ http://issues.apache.org/jira/browse/TUSCANY-688?page=all ]
Meeraj Kunnumpurath updated TUSCANY-688:
Attachment: tuscany-webapp-sample-patch-20060906.txt
Updated the POM to reflect support for default bootLibs and optional extensions.
>
[ http://issues.apache.org/jira/browse/TUSCANY-688?page=all ]
Meeraj Kunnumpurath updated TUSCANY-688:
Attachment: tuscany-war-patch-20060906.txt
Made the following changes,
1. extensions and bootLibs are optional
2. bootLibs if not specified
Hi,
I finally got the first sample (String<-->DOM) up and running with the
databinding framework integrated with the core with some workarounds/hacks.
The following is a list of issues and assumptions during the process. I
would like to get your opinions so that we can finalize the integration
Thanks for the patch Andy. I do have a few comments that I hope you
can address :-)
Would it be possible to break this down a little - there are changes
in there to the startup code and to the Spring container - is it
possible to separate those so that there is less to tackle in one go?
F
I think this is asking for trouble for several reasons. We really
should have one definitive source for the build. These artifacts
are bound to break and there is no realistic way to verify that
they work short of loading them in the tool they were intended for.
There is still only one de
[ http://issues.apache.org/jira/browse/TUSCANY-698?page=all ]
Jean-Sebastien Delfino resolved TUSCANY-698.
Resolution: Fixed
Assignee: Jean-Sebastien Delfino
Committed the patch, Thanks!
I guess we can close this one we'll create many
Jean-Sebastien Delfino wrote:
[snip]
I just tried it and was able to import our VC7 solution into it. I ran
into two issues:
- A minor issue, I had to remove the ODBC libraries from the link
configuration
- A more serious issue, the SDO runtime breaks with exceptions
complaining about "incompa
On Sep 6, 2006, at 8:18 PM, Jim Marino wrote:
On Sep 6, 2006, at 6:16 PM, Jeremy Boynes wrote:
On Sep 6, 2006, at 5:07 PM, [EMAIL PROTECTED] wrote:
Author: rfeng
Date: Wed Sep 6 17:07:19 2006
New Revision: 440909
URL: http://svn.apache.org/viewvc?view=rev&rev=440909
Log:
Replace ${sca.ver
Oisin Hurley wrote:
[snip]
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 ;)
Hi Oisin,
Did you get a chance to look into the MacOS X port? I have
On Sep 6, 2006, at 6:16 PM, Jeremy Boynes wrote:
On Sep 6, 2006, at 5:07 PM, [EMAIL PROTECTED] wrote:
Author: rfeng
Date: Wed Sep 6 17:07:19 2006
New Revision: 440909
URL: http://svn.apache.org/viewvc?view=rev&rev=440909
Log:
Replace ${sca.version} in the SCDL files with 1.0-SNAPSHOT since
With the few minor changes that I just checked in, and thanks to Axis2C
0.93, any SCA component deployed to Axis2 can now be invoked directly
from your Web browser using REST / HTTP GET style.
Here is how to do it with the Calculator sample (the steps are for
Linux, should be very similar on W
[ http://issues.apache.org/jira/browse/TUSCANY-699?page=all ]
Jeremy Boynes reassigned TUSCANY-699:
-
Assignee: Jeremy Boynes
> Allow bootstrap of tuscanny from spring web apps / struts apps etc
> --
Well, I can load it, but it's desperately empty :)
Given the following XML:
JaneDoe
I have no XSD for this document, and don't want to have one or have to
define specific SDO types for it. I just want to load this XML into an
SDO DataObject.
XMLDocumentPtr doc = XMLHelper::load(xml);
gives m
On Sep 6, 2006, at 5:07 PM, [EMAIL PROTECTED] wrote:
Author: rfeng
Date: Wed Sep 6 17:07:19 2006
New Revision: 440909
URL: http://svn.apache.org/viewvc?view=rev&rev=440909
Log:
Replace ${sca.version} in the SCDL files with 1.0-SNAPSHOT since
IDEs such as Eclipse cannot honor it.
Specifica
[ http://issues.apache.org/jira/browse/TUSCANY-670?page=all ]
Frank Budinsky resolved TUSCANY-670.
Resolution: Fixed
Fixed in revision 440915.
> SDO spi to cause serialization of dynamically created Types
> --
On Sep 6, 2006, at 3:51 PM, Raymond Feng wrote:
Hi,
I think I'm going to leave databinding-framework as an extension
for now. It won't impact the integration effort this stage. When
the code becomes more mature (in terms of test coverage and
functions), I'll merge it into the core/spi an
[
http://issues.apache.org/jira/browse/TUSCANY-696?page=comments#action_12433000
]
Scott Boag commented on TUSCANY-696:
> do you know where is the p0: is from
It's a manufactured prefix, 'cause the SDO lost the prefix info I think, which
w
Hi,
I tested our C++ Web Service support with Axis2C 0.93 on Linux and it
works with no code change. The only thing you need to do, after you
install Axis2C 0.93 and point your AXIS2C_HOME to it, is to turn the
MTOM (the SOAP Message Transmission Optimization Mechanism) support off
in axis2.x
I'm not sure about this. The DocumentRoot contains the global properties,
but the current SDO spec doesn't say how they are handled. So, for now, I
think it's best to leave the DocumentRoot in the list. Maybe a JIRA to
track it would be good.
Frank.
"Robbie Minshall" <[EMAIL PROTECTED]> wrote
Hi,
I think I'm going to leave databinding-framework as an extension for now. It
won't impact the integration effort this stage. When the code becomes more
mature (in terms of test coverage and functions), I'll merge it into the
core/spi and the work should be very trivial.
Thanks,
Raymond
Update to website
-
Key: TUSCANY-703
URL: http://issues.apache.org/jira/browse/TUSCANY-703
Project: Tuscany
Issue Type: Improvement
Components: Website
Reporter: David Wheeler
Fixes:
Title backgrounds
[ http://issues.apache.org/jira/browse/TUSCANY-670?page=all ]
Yang ZHONG updated TUSCANY-670:
---
Attachment: SerializeTypes.670
The full path version of the patch
> SDO spi to cause serialization of dynamically created Types
> --
TypeHelper.define is returning the DocumentRoot Type within the List of
defined Types. I am assuming that it should not do so but should rather
just return a list of the SDO Types defined in the xsd. Please correct me
if I am wrong here but otherwise I will open a JIRA and put in a fix
tomorrow
[ http://issues.apache.org/jira/browse/TUSCANY-696?page=all ]
Robbie Minshall updated TUSCANY-696:
Attachment: robbieResults_1.txt
attached junit update for initial test run that I executed.
> XMLStreamHelper usage
> -
>
>
[
http://issues.apache.org/jira/browse/TUSCANY-696?page=comments#action_12432980
]
Robbie Minshall commented on TUSCANY-696:
-
I just wrote a quick junit test that essentially does what you do with the
company xsd and xml files as well a
I think Raymond and I have the same concern over this is that we
basically take away from the user any control over where artifacts
come from. They don't get portability because different runtimes/
hosts may interpret the attribute differently and we can't specify
behaviour because the conce
My concrete proposal as one of the alternatives to scdlResource (pro and con
varies of course),
is to enhance from
new URL(current, scdlLocation) // thank Jeremy for clarifying
to trying other resources with the same relative path in ClassPath after the
new URL fails.
For other programming la
I have uploaded a zip file to TUSCANY-702 where I updated the DAS overview
and also create a Java DAS page contents targeting application developers
with the following items :
- DAS references/articles/etc
- DAS key features, project structure and high level class diagram
- DAS build instru
[ http://issues.apache.org/jira/browse/TUSCANY-702?page=all ]
Luciano Resende updated TUSCANY-702:
Attachment: lresende.tuscany702.20060906.zip
Updated xml files containing contents for site-author\das_index.xml and
site-author\java_das_overview.xml
Provide updated contents for DAS website page and create new DAS Java Overview
website page
---
Key: TUSCANY-702
URL: http://issues.apache.org/jira/browse/TUSCANY-702
[ http://issues.apache.org/jira/browse/TUSCANY-670?page=all ]
Yang ZHONG updated TUSCANY-670:
---
Attachment: SerializeTypesTestCase.java
Please add into the version control:
tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/test
> SDO spi to cause
[ http://issues.apache.org/jira/browse/TUSCANY-670?page=all ]
Yang ZHONG updated TUSCANY-670:
---
Attachment: SerializeTypes.670
See following attachment for a Test Case
> SDO spi to cause serialization of dynamically created Types
>
[
http://issues.apache.org/jira/browse/TUSCANY-153?page=comments#action_12432955
]
Robbie Minshall commented on TUSCANY-153:
-
LOADING SIMPLE CHANGE SUMMARY
When I attempt to load the simple change summary contained within the fix I get
[
http://issues.apache.org/jira/browse/TUSCANY-153?page=comments#action_12432954
]
Robbie Minshall commented on TUSCANY-153:
-
COMPANY WITH CHANGE SUMMARY PROPERTY
Rather than using a new type to wrap an existing type with a changeSummar
On Sep 6, 2006, at 11:44 AM, Yang ZHONG wrote:
I assumed "with relative URLs being resolved against the location
of the
containing scdl"
resolves against the full path/URL of the containing scdl. Never
mind if the
assumption was wrong.
I think that's the difference - relative URLs are res
Conversion to date types which do not include month can give incorrect results
--
Key: TUSCANY-701
URL: http://issues.apache.org/jira/browse/TUSCANY-701
Project: Tuscany
NPE in TuscanySessionListener.sessionDestroyed when Tomcat session expires
--
Key: TUSCANY-700
URL: http://issues.apache.org/jira/browse/TUSCANY-700
Project: Tuscany
Iss
Ok, no worries :-) I will prod through the Maven source. I think
Chris's post has got all I need.
Ta
Meeraj
-Original Message-
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: 06 September 2006 19:28
To: tuscany-dev@ws.apache.org
Subject: Re: Tuscany war plugin
On Sep 6, 2006, at 10
I assumed "with relative URLs being resolved against the location of the
containing scdl"
resolves against the full path/URL of the containing scdl. Never mind if the
assumption was wrong.
The response sounds applying relative path directly to
classLoader.getResource,
I wonder if that's the true
[
http://issues.apache.org/jira/browse/TUSCANY-699?page=comments#action_12432929
]
Jeremy Boynes commented on TUSCANY-699:
---
I would (strongly) prefer we do not introduce a dependency on clogging.
> Allow bootstrap of tuscanny from spring
I guess Yang was proposing to treat the scdlLocation classpath-aware instead
of adding a new "scdlResource" attribute.
I think it's better to have a separate attribute with clean semantics
because people usually assume location is a URI.
Thanks,
Raymond
- Original Message -
From: "J
[ http://issues.apache.org/jira/browse/TUSCANY-699?page=all ]
Andy Piper updated TUSCANY-699:
---
Attachment: springlaunch.patch
> Allow bootstrap of tuscanny from spring web apps / struts apps etc
> ---
Maybe, although this might also be relevant for a pure Spring host
(i.e. no webapp). I think we need to get more info from Andy on what
he has in mind (e.g. the patch :-) )
--
Jeremy
On Sep 6, 2006, at 11:17 AM, Meeraj Kunnumpurath wrote:
Jeremy/Andy,
Would this overlap with the war plugi
On Sep 6, 2006, at 10:57 AM, Meeraj Kunnumpurath wrote:
Jeremy,
1 & 4 are done. I am scratching my head around understanding the usage
of ArtifactResolver.resolveTransitively() from the Maven artifact API.
Do you have any idea?
Sorry, not really.
Also any pointers to the required servlet co
You lost me.
On Sep 6, 2006, at 10:50 AM, Yang ZHONG wrote:
Maybe we can broaden "relative path" semantics therefore it may not
necessarily be mandatory any longer to introduce "scdlResource".
e.g. the ClassPath is dir1, dir2, jar1, jar2.
Even if a resolved relative path is dir1/com/example/in
[
http://issues.apache.org/jira/browse/TUSCANY-696?page=comments#action_12432924
]
Robbie Minshall commented on TUSCANY-696:
-
I will take a look at this later this afternoon.
> XMLStreamHelper usage
> -
>
>
Jeremy/Andy,
Would this overlap with the war plugin stuff?
Ta
Meeraj
-Original Message-
From: Andy Piper (JIRA) [mailto:[EMAIL PROTECTED]
Sent: 06 September 2006 19:05
To: tuscany-dev@ws.apache.org
Subject: [jira] Created: (TUSCANY-699) Allow bootstrap of tuscanny from
spring web apps
Allow bootstrap of tuscanny from spring web apps / struts apps etc
--
Key: TUSCANY-699
URL: http://issues.apache.org/jira/browse/TUSCANY-699
Project: Tuscany
Issue Type: Improve
Jeremy,
1 & 4 are done. I am scratching my head around understanding the usage
of ArtifactResolver.resolveTransitively() from the Maven artifact API.
Do you have any idea?
Also any pointers to the required servlet context listener, filter and
servlet (if they exist) will be highly appreciated.
[ http://issues.apache.org/jira/browse/TUSCANY-694?page=all ]
Kevin Williams closed TUSCANY-694.
--
Resolution: Fixed
Verified with revision: 440808
> Update DAS sample distribution
> --
>
> Key: TUSCANY-694
>
Maybe we can broaden "relative path" semantics therefore it may not
necessarily be mandatory any longer to introduce "scdlResource".
e.g. the ClassPath is dir1, dir2, jar1, jar2.
Even if a resolved relative path is dir1/com/example/included.scdl,
we can also search for dir2/com/example/included.s
On Sep 6, 2006, at 9:49 AM, ant elder wrote:
I've used Clover in the past and Cobertura since Dan mentioned it
here a
while ago. Cobertura is really really easy and works today, just
use mvn
cobertura:cobertura and it generates coverage reports in
target\site\cobertura. Thats so easy I'd re
If there are no external dependencies on databinding, my preference
would be for the extension pieces to be merged with SPI and the impl
to be placed in core under /services. Before that happens, though,
I'd also like to see a lot more test coverage in place, particularly
unit testing. Inte
Hi,
I'm in the middle of integrating databinding framework with core/spi and it's
time to make a decision on the packaging.
There are two options for the databinding-framework.
1) Merge with core/spi: Move the interfaces/base classes into spi and
implementation into core.
2) Keep databinding-f
I've used Clover in the past and Cobertura since Dan mentioned it here a
while ago. Cobertura is really really easy and works today, just use mvn
cobertura:cobertura and it generates coverage reports in
target\site\cobertura. Thats so easy I'd really prefer this over Clover
unless Clover can also
With TUSCANY-674 I have finished remaining issues around DAS distribution
for the next release of Tuscany DAS :
distribution\das - DAS binaries and dependencies
distribution\das-samples - DAS samples shipped in a ready-to-deploy war
file with all dependencies and sources includ
Hi All,
I thought I'd check-in regarding the status of this request? Kevin was kind
enough to log jira issue (http://issues.apache.org/jira/browse/TUSCANY-670),
but I'm blocked. Any chance there is a workaround available? I'd like to
use the DAS for DB access, but would be willing to map to/fro
[ http://issues.apache.org/jira/browse/TUSCANY-674?page=all ]
Kevin Williams closed TUSCANY-674.
--
Fix Version/s: Java-Mx
Resolution: Fixed
Verified with revision: 440754
> DAS: Modify test framework to facilitate support for new vendors
> --
The spec says that takes the name of the composite to be
included but does not say how it should be located. We currently
support a scdlLocation attribute that takes a URL, with relative URLs
being resolved against the location of the containing scdl.
However, it would be nice to allow use
[
http://issues.apache.org/jira/browse/TUSCANY-153?page=comments#action_12432874
]
Robbie Minshall commented on TUSCANY-153:
-
FYI. All very striaght forward but in order to apply the patch I had to
perform the following
1. new files
For each sample project I think that it is a good idea to include an
overview javadoc page that includes information about common setup etc.
This would include essentually the same information that you outlined for
the readme but provides a good means to link to external docs like
specifications,
Sounds great.
When Venkat is done with his port I would be interested in helping. Perhaps
a sample demonstrating interopt between services with different language
implementations.
If we are using SDO for our data model how will SDO support be provided in
these container extensions ?
Robbie
[
http://issues.apache.org/jira/browse/TUSCANY-697?page=comments#action_12432849
]
Geoff Winn commented on TUSCANY-697:
Patch file built and tested on RHEL 3 and XP with MSVC 6 and 7.
> [C++ for SDO] Add remaining methods taking SDOString a
[ http://issues.apache.org/jira/browse/TUSCANY-697?page=all ]
Attachment: TUSCANY-697.patch
> [C++ for SDO] Add remaining methods taking SDOString args rather than char*
> ---
>
> Key: TUSCANY-697
>
On 9/6/06, Simon Laws <[EMAIL PROTECTED]> wrote:
On 9/6/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I just checked in the beginning of a Ruby extension under
>
>
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/ruby/
> .
>
> It is not complet
Hi... I am interested in taking a look at this. I hope to get a feel of
implementing container extensions through this. I shall get started with
this rightaway.
Ant, I might need your help for this after I do some ground work.
Thanks.
- Venkat
On 9/6/06, ant elder <[EMAIL PROTECTED]> wrote:
Quite a while back we had a Ruby container contributed for the Java runtime,
see TUSCANY-365. Is anyone interested in looking at porting that to the new
Java runtime and getting it to match what the C++ guys are doing?
...ant
On 9/6/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Hi al
On 9/6/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Andy,
I checked in an initial version of Calculator which demonstrates your
Python extension under
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/PythonCalculator/
.
More work is necessary to make it complete, sho
On 9/6/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Hi all,
I just checked in the beginning of a Ruby extension under
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/ruby/
.
It is not complete but it allows you to declare an SCA component
implemented by a
Earlier I created a patch for a first pass at a PHP extension for C++ SCA (
http://issues.apache.org/jira/browse/TUSCANY-698)
This follows the pattern layed down by Andy with the Python extension and
has many limitations::
Services only. No references.
Basic input types only. No arrays or SD
Hi all,
I just checked in the beginning of a Ruby extension under
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/ruby/.
It is not complete but it allows you to declare an SCA component
implemented by a Ruby class with for example:
Support for references, pr
Andy,
I checked in an initial version of Calculator which demonstrates your
Python extension under
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/PythonCalculator/.
More work is necessary to make it complete, show a Python client, usage
of SCA references in a Python compon
On 9/5/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Hi,
I checked in a copy of Calculator under
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/Calculator-new/
,
with a number of changes trying to simplify the sample and improve the
consistency of the names used in t
[ http://issues.apache.org/jira/browse/TUSCANY-698?page=all ]
Simon Laws updated TUSCANY-698:
---
Attachment: phpextensioncalculatorchangespatch.txt
apply to sca/samples/Calculator
> First pass PHP extension for C++ SCA
>
[ http://issues.apache.org/jira/browse/TUSCANY-698?page=all ]
Simon Laws updated TUSCANY-698:
---
Attachment: phpextension1patch.txt
apply to sca/runtime/extensions
> First pass PHP extension for C++ SCA
>
>
>
First pass PHP extension for C++ SCA
Key: TUSCANY-698
URL: http://issues.apache.org/jira/browse/TUSCANY-698
Project: Tuscany
Issue Type: Improvement
Components: C++ SCA
Affects Versions: Cpp
[C++ for SDO] Add remaining methods taking SDOString args rather than char*
---
Key: TUSCANY-697
URL: http://issues.apache.org/jira/browse/TUSCANY-697
Project: Tuscany
I
On 9/6/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Andrew Borley wrote:
[snip]
> A few issues came up when I was developing the extension:
> 1) The code currently depends on the CPP extension code, specifically
for
> the interface.cpp which is used by the extension just to get the scop
78 matches
Mail list logo