[
https://issues.apache.org/jira/browse/TUSCANY-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amita Vadhavkar updated TUSCANY-961:
Attachment: 961.patch
List of files changed:
*1) DAS
-set/get for helperContext
Please check patch for JIRA-961. A,B,C is the approach followed.
Regards,
Amita
On 8/1/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
ASo far, RDB DAS was doing SDOUtil.createTypeHelper() during each
construction of GraphBuilderMetadata(GBMD). This was resulting in a new
instance fo TypeHelper
Just now, I found that the service name=[name], name here must equal to the
java interface's name, as well the service's name of WSDL, other wise, we just
see NullPointerException.
I would suggest generate a guiding Exception, to tell the developer this rule
of defining a service.
I agree with Amita that for clarity is better to let the user set the
parameter name, for all those reasons she has argued on this thread so far.
But, I don't I agree with to use the [1] instead of [2], because it's not a
good practice to define the parameter names on only one string separated by
We have done some further investigation and here are the findings:
We have configured the J2SE enviroment to use Yoko ORB (the one used by
Geronimo) instead of the JVMs and running the testcase resulted in a
MarshalException. We suspect it is an issue with Yoko ORB.
Vamsi
On 8/3/07, ant elder
Hi,
Thank you for the hint. I'm able to identify an issue in the Yoko ORB. The
problem is in class:
http://svn.apache.org/viewvc/incubator/yoko/trunk/core/src/main/java/org/apache/yoko/orb/CORBA/InputStream.java?revision=555715view=markup
Method private String getIDLStubClassName(Class c)
PITA is a new one on me. I usually use Google to help me in such
cases, but most of the entries near the top of the list are about
a kind of bread :-)
I don't see this as such a big problem. The average WSDL file
seems to contain at least 3 different namespaces. I think XML
programmers are
A Jira (https://issues.apache.org/jira/browse/TUSCANY-1504) has been
raised against the SDO C++ implementation which is saying that for a
schema:
?xml version=1.0 encoding=UTF-8?
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:letter=http://letterSchema;
In RDBMS and in DAS OUTER JOINs are used quite frequently. By definition
it means, all rows from parent and matching rows from child. So, there is a
chance for having complete null rows from child and that is the purpose of
OUTER JOIN.
So there are different situations
1) complete child row is
According to line 1498 on page 34 of the Assembly spec[1] it doesn't sound
like thats correct:
1498 • name (required) – the name of the service, the name MUST BE unique
across all the
1499 composite services in the composite. The name of the composite service
can be different
1500 from the name
[
https://issues.apache.org/jira/browse/TUSCANY-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Grove updated TUSCANY-1397:
Attachment: tuscany1397-v2.patch
This patch replaces the previous version. This patch was
Thanks Adriano, Fuhwei,
I've re-created the patch using the trunk code as at revision 562418 and
attached it to the JIRA.
I'm happy to submit the patch directly if everyone is happy with the
approach I'm taking on this issue.
Thanks,
Andy.
-Original Message-
From: [EMAIL PROTECTED]
Wouldn't this cause breakage in the scenario that I described, where
foo from Tuscany later turns into foo as part of SCA but with some
differences? Any SCDLs written to just use plain foo would break
when Tuscany steps up to support the SCA foo.
Simon
ant elder wrote:
How about having the
[
https://issues.apache.org/jira/browse/TUSCANY-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brady Johnson updated TUSCANY-1438:
---
Attachment: samples.CppBigBank.build.xml
Uploading the build.xml file for the CppBigBank
I'll jump in though I might be missing some context... ...
I wonder if Shaoguang is describing the fact that the component service name
must match the implementation service name when you are configuring the
component via SCDL (rather than making a statement about the composite
service name).
Hi, Ant.
Good point. It seems that Geronimo is very close to have the 2.0 release out
and hopefully we can move to it soon.
Thanks,
Raymond
- Original Message -
From: ant elder [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Friday, August 03, 2007 2:37 AM
Subject: Re: svn
[
https://issues.apache.org/jira/browse/TUSCANY-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amita Vadhavkar updated TUSCANY-1464:
-
Attachment: 1464.patch
please see reply on ML
Regards,
Amita
Wrong query results
Just a reminder we can't release with snapshot dependencies so we'll if
there's something we require in these OpenEJB and Geronimo snapshots then we
wont be able to include the EJB binding in a Tuscany release till there's
non-snapshot releases we can use.
...ant
On 8/3/07, [EMAIL PROTECTED]
How about having the Tuscany namespace extend the SCA one so you can choose
to use that as the default namespace so as to avoid having to worry about
all the namespace prefixes?
...ant
I don't really expect to win this debate now that the issue has been brought
up, had just been hoping it
ant elder wrote:
Taking that line of thought and you hit the long thread associated with:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL
PROTECTED]
which is what I was hoping to quietly ignore by just keeping everything in
the one SCA namespace.
...ant
On
Thanks Raymond. It works now. I will report the issue to Yoko mailing
lists.
Vamsi
On 8/3/07, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
Thank you for the hint. I'm able to identify an issue in the Yoko ORB. The
problem is in class:
Doug Tidwell wrote:
Friends, I'm working on a demo to illustrate the flexibility SCA provides
to client applications. I want to take the exact same code and use it to
invoke different services using different access methods, etc., without
changing the code. As I see it, there are three ways
[
https://issues.apache.org/jira/browse/TUSCANY-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517584
]
Matthew Schultz commented on TUSCANY-1504:
--
Check the spec but you might be right. I am able to access
On 8/3/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
ant elder wrote:
Taking that line of thought and you hit the long thread associated with:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL
PROTECTED]
which is what I was hoping to quietly ignore by
Terrific - Thanks!
Luciano Resende (JIRA) wrote:
[
https://issues.apache.org/jira/browse/TUSCANY-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luciano Resende resolved TUSCANY-1495.
--
Resolution: Fixed
Patch applied
Fix RAT issues in DAS LDAP
--
Key: TUSCANY-1506
URL: https://issues.apache.org/jira/browse/TUSCANY-1506
Project: Tuscany
Issue Type: Bug
Components: Java DAS LDAP
Affects Versions: Java-DAS-Next
[
https://issues.apache.org/jira/browse/TUSCANY-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luciano Resende updated TUSCANY-1506:
-
Attachment: ldap-rat.log
Fix RAT issues in DAS LDAP
--
[
https://issues.apache.org/jira/browse/TUSCANY-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517504
]
Ron Gavlin commented on TUSCANY-761:
Frank, I would not expect the runtime to manage dependencies in this case.
On 6/30/07, ant elder [EMAIL PROTECTED] wrote:
With the SCA 0.91 release now being voted on how about starting on 0.92?
I've already been adding some things I'm interested in getting done to the
next release wiki page -
Taking that line of thought and you hit the long thread associated with:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL
PROTECTED]
which is what I was hoping to quietly ignore by just keeping everything in
the one SCA namespace.
...ant
On 8/3/07, Simon Nash
Hi Ant... thanks for bringing this up again. Yes, the week ending Aug
17th seems good if we plan to release end of August.
I'd prefer 0.95 for the next release.
- Venkat
On 8/3/07, ant elder [EMAIL PROTECTED] wrote:
On 6/30/07, ant elder [EMAIL PROTECTED] wrote:
With the SCA 0.91 release
ant elder wrote:
On 8/1/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
[snip]
Another problem is all our bindings work differently. So
binding.ws/,
binding.rmi/ binding.jms/
Hi Luciano,
I looked at the RAT log and noticed that I ended up including the server-work
directory in the zip. Could you please delete this from subversion. The
server-work directory is created when ApacheDS is started in embedded mode by
the tests.
I'll start patching the non-licensed
[snip]
Simon Nash wrote:
See inline.
Simon
Jean-Sebastien Delfino (JIRA) wrote:
[
https://issues.apache.org/jira/browse/TUSCANY-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516845
]
Jean-Sebastien Delfino commented on TUSCANY-1499:
[snip]
Luciano Resende wrote:
I have fixed this under revision #561972, we now utilize the
contribution file name or it's location (in case of a folder) to
construct the contribution URI.
On 7/30/07, Luciano Resende [EMAIL PROTECTED] wrote:
Looks like DefaultSCADomain is always setting
Raymond Feng wrote:
Hi,
Is it different from
http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-commonj_1.1_spec/1.0/?
If not, we can use the geronimo one and remove our own. Otherwise,
renaming the artifact id to tuscany-commonj-api sounds good to me.
Thanks,
Raymond
Hi Raymond,
Sorry for the late reply, your e-mail passed through my filters :) The
approach described in the document sounds good to me, it's similar to what
we're doing for import resolution within an ODE deployment package. So that
should work. The only part I'm not so clear about though is
The loading of contribution has two phases : read and resolve.
* read phase : This is where you read an artifact (a document, an
XML element, classes etc.), populate a model representing the artifact
and return it. The SCA contribution service calls
ArtifactProcessor.read() on all artifacts
[
https://issues.apache.org/jira/browse/TUSCANY-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517631
]
Adriano Crestani commented on TUSCANY-1464:
---
Replies on
Hi Amita,
Great work you are doing : ). You are correct about the outer join case, I
hadn't remember this use case. Yes, DAS should ignore a row completely null,
but only when it's completely null, any other data in it, DAS should throw
an exception.
Thanks for the explanation about the static
Applyed the new patch, tests ran OK, commited.
Adriano Crestani
On 8/3/07, Andy Grove [EMAIL PROTECTED] wrote:
Thanks Adriano, Fuhwei,
I've re-created the patch using the trunk code as at revision 562418 and
attached it to the JIRA.
I'm happy to submit the patch directly if everyone is
Hey Andy,
It should be OK for you to committ it directly, if you need a
review just forward the committ log and ask people to review (but I
guess they will be reviewing it anyway from the mail notifications).
On 8/3/07, Adriano Crestani [EMAIL PROTECTED] wrote:
Andy, please, check if
+1
The sample artifacts aren't really be distributed in the maven repository
are they so should be deleted from the temp repo? Also none of the maven
artifacts are signed. Both of those can be fixed keeping the release
distributions as-is though without a requiring any respin.
A lot of the
Jean-Sebastien Delfino wrote:
Raymond Feng wrote:
Hi,
Is it different from
http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-commonj_1.1_spec/1.0/?
If not, we can use the geronimo one and remove our own. Otherwise,
renaming the artifact id to tuscany-commonj-api sounds good
44 matches
Mail list logo
