I'll wipe my maven repo of contribution artifacts and rerun - I guess I need
to alter the build sequencing a bit.
Kelvin.
2009/6/20 ant elder
> On Fri, Jun 19, 2009 at 1:49 PM, kelvin goodson
> wrote:
> > I'm just about to check in a build structure for the 2.x otests. It's
> > a step forward,
Thanks for reviewing. With the things already fix and if we can fix
most of these today how about we aim for doing an RC2 tomorrow, and
that will give a little more time for anyone else to review/update as
well. Some comments in line...
On Sat, Jun 20, 2009 at 12:47 PM, Simon Laws wrote:
> Binar
On Mon, Jun 22, 2009 at 9:44 AM, ant elder wrote:
> Thanks for reviewing. With the things already fix and if we can fix
> most of these today how about we aim for doing an RC2 tomorrow, and
> that will give a little more time for anyone else to review/update as
> well. Some comments in line...
+1
dynamic sdo databinding for wsdltoJava-cxf
--
Key: TUSCANY-3115
URL: https://issues.apache.org/jira/browse/TUSCANY-3115
Project: Tuscany
Issue Type: New Feature
Environment: ubuntu 8.10, jdk1.
[
https://issues.apache.org/jira/browse/TUSCANY-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pradeep Fernando updated TUSCANY-3115:
--
Attachment: Tuscany-3115.patch
I have created a seperate module for databinding hooku
Went back and re-tried samples/calculator-rmi-service&reference and it
worked. I don't know why this sample alone didn't work when I went
through them initially.
Simon
Looked at some of the webapps also.
Not sure what to do with helloworld
helloworld-jsf deployed on tomcat leads to [1]
helloworld-jsp works ok. Which ones of these samples should I expect
to be able to use on Tomcat?
Also still having problems building the webapp samples with maven if I
remove
On Fri, Jun 19, 2009 at 10:15 PM, Raymond Feng wrote:
> Hi, Simon.
>
> Good progress!
>
> I'm trying to run the two nodes itest using the distributed endpoint
> registry. When the endpoint is looked up, I check if the primary member for
> the entry to see if it is the same as the local member to se
On Mon, Jun 22, 2009 at 1:15 PM, Simon Laws wrote:
>> 3) We need to map it to an absolute WS URI when it publishes to the endpoint
>> registry (Simon already mentioned that we need to have base URIs for a given
>> node. For the moment, we can just use http://localhost:8080/ as the default)
>> so t
I actually thought i'd changed the webapp pom.xml's to use the same as the
webapp archetypes generate, so they wouldn't have any dependency on the
tuscany pom.xml hierarchy, but doesn't look like thats there so i mustn't
have committed it, i shall do that today and that will hopefully fix the
build
On Mon, Jun 22, 2009 at 1:46 PM, ant elder wrote:
> when
> the tuscany runtime needs to be distributed across JVMs maybe we
> should look at a Tribes based transport for the SCA binding as that
> could use the same config as the Tribes based endpoint registry.
>
Having thought about this for a bi
[
https://issues.apache.org/jira/browse/TUSCANY-3097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws reassigned TUSCANY-3097:
---
Assignee: Simon Laws
> External ear contribution processes all composite files in a Java EE
On Mon, Jun 22, 2009 at 1:46 PM, ant elder wrote:
> On Mon, Jun 22, 2009 at 1:15 PM, Simon Laws wrote:
>
>>> 3) We need to map it to an absolute WS URI when it publishes to the endpoint
>>> registry (Simon already mentioned that we need to have base URIs for a given
>>> node. For the moment, we can
operationProperties attribute gets discarded
Key: TUSCANY-3116
URL: https://issues.apache.org/jira/browse/TUSCANY-3116
Project: Tuscany
Issue Type: Bug
Components: Java SCA JMS Binding E
Hi,
It seems that we haven't published some of the artifacts into the maven repo
for Tuscany SCA 2.0-M2. Can we just go ahead to deploy them or do we need a
vote?
I deployed the tuscany-feature-* last night as I thought we forgot to do so
for the M2 release. If we need a vote, I'll have to r
Not really. I just downloaded the distro and confirmed the issue related to
woden-impl-dom:
Steps to reproduce the issue:
1) C:\Apache\tuscany-sca-2.0-M3\modules>java -jar
osgi-3.4.0-v20080605-1900.jar -co
nfiguration ..\features\configuration -clean -console
osgi> install
file:/C:/Apache/t
So this is broken in 2.x trunk as well then, so i'm still feeling at this
late stage this just missed the M3 boat. From whats been said it sounds like
the options are:
1) just pull the dosgi samples from M3 and get them working for the next
release
2) fix whatever is broken in trunk, merge those c
This is not broken in 2.x trunk. In distribution/all/pom.xml, we use the latest
maven-bundle-plugin which fixed the problem:
org.apache.tuscany.maven.plugins
maven-bundle-plugin
1.0.3-SNAPSHOT
Thanks,
Raymond
From: ant elder
Sent: Monday, June
I'm on the same page as Simon. The distributed endpoint registry is an
effort to shield the physical locations from the logical SCA addresses
(componentURI/serviceName/bindingName). For binding.sca, we map it to a
remote protocol for cross-JVM cases, such as WS, RMI/IIOP. We'll look up the
phys
hello devs/raymond.
you talked about adding axiom databinding in the tooling. I went through the
documentation / code .just to clarify , you are talking about
ADB databinding isnt it.
http://ws.apache.org/axis2/1_5/adb/adb-howto.html
ADB is the databinding mechanism that creates the related clas
Not really, I meant to be using OM nodes/elements as the types. For example:
OMElement op(OMElement arg0, String arg1, OMElement arg3);
Thanks,
Raymond
From: Pradeep Fernando
Sent: Monday, June 22, 2009 11:15 AM
To: tuscany-dev
Subject: adding axiom databinding in wsdltoJava tool.
hello dev
[
https://issues.apache.org/jira/browse/TUSCANY-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Feng reassigned TUSCANY-3115:
-
Assignee: Raymond Feng
> dynamic sdo databinding for wsdltoJava-cxf
> -
>
> Not really, I meant to be using OM nodes/elements as the types. For
> example:
>
> OMElement op(OMElement arg0, String arg1, OMElement arg3);
>
you mean using axiom as the manipulation mechanism.
hmm
then only databinding we need is SDO. and we want axiom ,DOM & stax as our
manipulation mechan
I added READMEs and a diagram under
http://svn.apache.org/viewvc?rev=787401&view=rev.
Thanks,
Raymond
--
From: "Simon Laws"
Sent: Saturday, June 20, 2009 4:47 AM
To:
Subject: Re: [VOTE] Release Tuscany SCA 2.0 M3 RC1
There are a couple of date
Hi, Pradeep.
Thanks for the patch. I checked the code in.
A few comments:
Can you use SDO HelperContext/XSDTypeHelper APIs instead of EMF?
Can you try to use java generics for the collections if possible?
I'll have to wait for your test case to find out how to run the tool.
Raymond
---
Hi Lookman,
As I mentioned in our previous chat sessions, this week and next I will not
have regular access to email. On any chance I get to check email I will
check for any messages you might send. In any case, I advise you to continue
with your weekly updates and discussions on the dev list. The
On Jun 18, 2009, at 8:50 AM, ant elder wrote:
Please review and vote on RC1 of the SCA 2.0 M3 release.
The distribution artifacts, RAT reports, and Maven staging repository
are available for review at:
http://people.apache.org/~antelder/tuscany/2.0-M3-RC1/
The release tag is at:
http://svn.ap
>
> Can you use SDO HelperContext/XSDTypeHelper APIs instead of EMF?
> Can you try to use java generics for the collections if possible?
sure, ill try. thanks for the feedback.
I'll have to wait for your test case to find out how to run the tool.
working on that. trying to use the CXF s method
On Mon, Jun 22, 2009 at 3:49 PM, Simon Laws wrote:
> On Mon, Jun 22, 2009 at 1:46 PM, ant elder wrote:
>> On Mon, Jun 22, 2009 at 1:15 PM, Simon Laws wrote:
>>
3) We need to map it to an absolute WS URI when it publishes to the
endpoint
registry (Simon already mentioned that we need
On Thu, May 14, 2009 at 3:45 PM, ant elder wrote:
> On Thu, May 14, 2009 at 3:15 PM, Simon Nash wrote:
>> Thanks for this proposal. It helps to see something concrete.
>> See questions/comments inline below.
>>
>> Simon
>>
>> ant elder wrote:
>>>
>>> On Thu, May 14, 2009 at 1:30 PM, Simon Nash
XSDModelResolver needs to handle namespace resolution
-
Key: TUSCANY-3117
URL: https://issues.apache.org/jira/browse/TUSCANY-3117
Project: Tuscany
Issue Type: Bug
Components: Java
Please vote on releasing 1.0.3 of the Tuscany Maven Bundle Plugin module.
The tag for the release is:
https://svn.apache.org/repos/asf/tuscany/maven-plugins/tags/maven-bundle-plugin-1.0.3/
the Maven staging repository is:
http://people.apache.org/~rfeng/tuscany/maven-bundle-plugin-1.0.3/
The
WSDL/XSD imports should use non-sca mechanism as first approach
---
Key: TUSCANY-3118
URL: https://issues.apache.org/jira/browse/TUSCANY-3118
Project: Tuscany
Issue Type: Bug
Include testcase to validate the non-sca mechanism of resolving artifacts
-
Key: TUSCANY-3119
URL: https://issues.apache.org/jira/browse/TUSCANY-3119
Project: Tuscany
Is
ant elder wrote:
On Thu, May 14, 2009 at 3:45 PM, ant elder wrote:
On Thu, May 14, 2009 at 3:15 PM, Simon Nash wrote:
Thanks for this proposal. It helps to see something concrete.
See questions/comments inline below.
Simon
ant elder wrote:
On Thu, May 14, 2009 at 1:30 PM, S
The XSDModelResolvers are basically used to resolve inline schemas, so using
a namespace import resolvers are not applicable in this case.
In case of XSD, the @schemaLocation is handled by
org.apache.ws.commons.schema.XmlSchemaCollection
for any path specified in the schemaLocation attribute. I be
On Wed, Jun 17, 2009 at 5:21 PM, Simon Laws wrote:
>
> So are you saying that we are currently not able to resolve XSDs by
> namespace alone?
>
> Simon
>
Hi Simon,
Yeah, currently we are not able to do that.
The URIResolver is now fixed to handle the namespace import resolution for
XSDModelReso
[
https://issues.apache.org/jira/browse/TUSCANY-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramkumar Ramalingam resolved TUSCANY-3117.
--
Resolution: Fixed
Committed revision 787566 in 2.x.
> XSDModelResolver needs
38 matches
Mail list logo
