Hi,
First i didn't get what you mean by "I started the server first, noted the
random port number
that was assigned, then built the client using that port number."
But I have tried with modifying the sample callback-ws-service in 1.1-RC3
I got the same exception that i have posted before...
follo
I apologies, i got your point about "noted the random port number that was
assigned, then built the client using that port number.".
In my previous mail I have only changed the "MyServiceImpl.java" as
mentioned in that mail. Now i have also changed the composite of
callback-ws-service as .
Hi,
I observe that the issues mentioned here have been fixed. The LICENSE file
is really clean and precise now (an additional thanks for this, Simon).
I've also run some samples successfully.
Here is my +1.
Thanks for getting this re-spin done.
- Venkat
On Jan 28, 2008 1:47 AM, Simon Laws <[E
Continuum VMBuild Server wrote:
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=43145&projectId=277
My fault, sorry, I didn't realize that my IDE had compiled the class and
mvn didn't recompile it. I just fixed the issue and restarted a build.
--
Jean-Sebasti
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=43145&projectId=277
Build statistics:
State: Failed
Previous State: Ok
Started at: Mon 28 Jan 2008 17:09:17 -0800
Finished at: Mon 28 Jan 2008 17:11:05 -0800
Total time: 1m 48s
Build Trigger: Schedule
Build Num
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=43145&projectId=277
Build statistics:
State: Failed
Previous State: Ok
Started at: Mon 28 Jan 2008 17:09:17 -0800
Finished at: Mon 28 Jan 2008 17:11:05 -0800
Total time: 1m 48s
Build Trigger: Schedule
Build Num
Comments inline.
Simon
Nishant Joshi wrote:
Hi,
I have followed as you have mentioned,
In step 2 you have mentioned to use RequestContext and get callback from it.
Here i have used ComponentContext.getRequestContext().getCallback() to get
the callback...(Not used callback injection)...
Now p
The binding-specific exception/fault mapping won't be exposed to the
programming model. I was proposing to make the mapping extensible so that we
can support multiple patterns without impacting the SCA application code.
Thanks,
Raymond
- Original Message -
From: "Scott Kurz" <[EMAIL P
I agree that this is where the mapping patterns are coming from.
But doesn't this undermine the
whole binding-independent programming model feature advertised by SCA?
Scott
On Jan 28, 2008 11:51 AM, Raymond Feng <[EMAIL PROTECTED]> wrote:
> Hi, Scott.
>
> I agree with you that the Fault<-->Except
Need a consitent way to handle generics in java interfaces and
method<-->operation mapping
--
Key: TUSCANY-2020
URL: https://issues.apache.org/jira/browse/TUSCANY-2020
Hi,
Starting with the J2SE based runtime sounds like a balanced approach. I
think the embedded HTTP support (Tomcat or Jetty) will provide us the
web-based UI capability to install/uninstall/list contributions and
deploy/undeploy composites. I also see great similarity with the
Tuscany/Geroni
Some errors were reported near the end of the build:
[INFO] [exec:java {execution: generate-test-sdo-source}]
>> Building project from dir:
D:\tuscany-sca-1.1-incubating-src\itest\databindings\sdogen\target
>> Processing greeter.composite.vm to
D:\tuscany-sca-1.1-incubating-src\itest\databindings\
We still only have services support. I'm in my final steps of
integrating the RuntimeComponent and the BPEL engine to allow for the
reference invocation. I'm using the new itests to drive the
integration.
On Jan 28, 2008 9:57 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> I've seen change
I've seen changes to the implementation-bpel and new itests. Could
somebody give a high level bullet list of what's supported now?
In particular are references supported and are there any limitations in
that support?
Thanks.
--
Jean-Sebastien
-
snip...
> I'm not too keen on scanning a disk directory as it doesn't apply to a
> distributed environment, I'd prefer to:
> - define a model representing a contribution repository
> - persist it in some XML form
>
I've started on some model code in my sandbox [1]. Feel free to use and
abuse.
R
Hi,
The previous VOTE thread here for SCA Java 1.1-incubating identified some
issues.
http://www.mail-archive.com/[EMAIL PROTECTED]/msg16483.html
A new release candidate (RC3a) has been created addressing the issues as
discussed in the previous thread. I'm starting this IPMC VOTE thread in
para
sebb wrote:
Seems to me it would be useful to create a binary archive without any
of the external jars.
This would considerably reduce the size of the archive.
Most of the jars are likely to remain the same between releases anyway.
+1
Many projects do that (Spring for example), you can down
Hi, Scott.
I agree with you that the Fault<-->Exception mapping pattern should be
independent of the databinding for the fault data. Generally speaking, the
mapping patterns are defined by the Web Service stack, for example, JAXWS,
JAXRPC or Axis2. We probably we need to make the mapping handl
On Jan 28, 2008 8:44 AM, sebb <[EMAIL PROTECTED]> wrote:
> Binary archives:
> ===
>
> The file:
> lib/ode-dao-jpa-ojpa-derby-1.1.zip
> is present in the binary archive, but probably should not be; or if it
> is, it should probably not be in the lib directory, as it is not a jar
> file.
>
T
[
https://issues.apache.org/jira/browse/TUSCANY-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563191#action_12563191
]
Sebb commented on TUSCANY-2019:
---
A few fixes for XML files:
svn ps svn:eol-style native it
Binary archives:
===
The file:
lib/ode-dao-jpa-ojpa-derby-1.1.zip
is present in the binary archive, but probably should not be; or if it
is, it should probably not be in the lib directory, as it is not a jar
file.
The LICENSE mentions
tuscany-assembly-xsd-1.1-incubating.jar
but that does
Most if not all issues raised on the IPMC seems to be fixed now, I
tried couple standalone samples as well web application samples and
all looks good.
Here is my +1
On Jan 28, 2008 12:18 AM, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On Jan 27, 2008 8:17 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
>
[
https://issues.apache.org/jira/browse/TUSCANY-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated TUSCANY-2019:
--
Description:
The SVN eol-style property needs to be set to "native" for .java, .xml and
other "text" files,
[
https://issues.apache.org/jira/browse/TUSCANY-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated TUSCANY-2019:
--
Attachment: addnative.txt
Add eol-style: native to some Java files (there are probably others that need
doin
[
https://issues.apache.org/jira/browse/TUSCANY-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated TUSCANY-2019:
--
Attachment: removeexexc.txt
Removes svn:executable from some java files that should not have it
> SVN eol-st
SVN eol-style property not set correctly on all source files
Key: TUSCANY-2019
URL: https://issues.apache.org/jira/browse/TUSCANY-2019
Project: Tuscany
Issue Type: Bug
On 28/01/2008, Simon Laws <[EMAIL PROTECTED]> wrote:
> On Jan 28, 2008 2:17 PM, sebb <[EMAIL PROTECTED]> wrote:
>
> > Seems to me it would be useful to create a binary archive without any
> > of the external jars.
> >
> > This would considerably reduce the size of the archive.
> >
> > Most of the j
On Jan 28, 2008 1:57 PM, sebb <[EMAIL PROTECTED]> wrote:
> It looks like the SVN eol-style:native properties have not been set up
> for some of the xml files, for example:
>
> modules/binding-dwr/pom.xml
>
> This causes problems when working on the files using both Windows and
> Unix.
>
> Also, a
On Jan 28, 2008 2:17 PM, sebb <[EMAIL PROTECTED]> wrote:
> Seems to me it would be useful to create a binary archive without any
> of the external jars.
>
> This would considerably reduce the size of the archive.
>
> Most of the jars are likely to remain the same between releases anyway.
>
> -
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson updated TUSCANY-1293:
Patch Info: [Patch Available]
> SDO does not work with OSGi
> ---
Seems to me it would be useful to create a binary archive without any
of the external jars.
This would considerably reduce the size of the archive.
Most of the jars are likely to remain the same between releases anyway.
-
To uns
It looks like the SVN eol-style:native properties have not been set up
for some of the xml files, for example:
modules/binding-dwr/pom.xml
This causes problems when working on the files using both Windows and Unix.
Also, at least one pom.xml has very strange properties:
Properties on 'modules\
Hi,
I have followed as you have mentioned,
In step 2 you have mentioned to use RequestContext and get callback from it.
Here i have used ComponentContext.getRequestContext().getCallback() to get
the callback...(Not used callback injection)...
Now problem here is in service side, following is the s
>
>
> Add the
> > code that loads all contributions that are available from the file
> system.
> > Ant already has this code in various forms
>
> We can do simpler than load "all contributions that are available from
> the file system" as the list of contributions to be loaded in a node is
> determ
Is "WARNING: Service not found for component service:" required for promoted
services?
---
Key: TUSCANY-2018
URL: https://issues.apache.org/jira/browse/TUSCANY-2018
On Jan 27, 2008 8:17 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
> A new release candidate has been created to address comments made on the
> IPMC Tuscany Java SCA 1.1-incubating RC3 VOTE thread on general@
>
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg16483.html
>
> The follow changes have b
36 matches
Mail list logo
