[
http://issues.apache.org/jira/browse/TUSCANY-470?page=comments#action_12416853
]
Kelvin Goodson commented on TUSCANY-470:
On further investigation I have determined that the code is worling as designed
and does handle xpath access to and through
Which code base are you intending to use: the M1 which implements the
old .9 spec or the sandbox one which implements support for the new
recursive model, or both?
In terms of how to specifically improve the extensibility story, my
opinions have been embodied in the sandbox code and
In trying to eliminate reliance on core2 by container.java in the
sandbox and have it only rely on the extensibility SPI, it occurred
to me that this would mandate moving a lot of implementation classes
from core2 into SPI. I believe having container.java as a separate
project rely on
I'm confused about this proposal. Didn't you say earlier that the php
tests would be added to the PECL repository? In which case the logical
place would be pecl/sdo/tests/interop/. But (I'm guessing) your
tuscanyphp directory is in the Apache repository. And why is it
tuscanyphp/ and not
Mmmm. My fault. I mean that to be pecl/php... not tuscanyphp.
On 6/20/06, Caroline Maynard [EMAIL PROTECTED] wrote:
I'm confused about this proposal. Didn't you say earlier that the php
tests would be added to the PECL repository? In which case the logical
place would be
I definitely agree that we should not be putting implementation into
spi. We've been down the duplication path before and it did not work -
the system and java containers quickly started to skew from each other
(e.g. autowire only works for system components).
Is there a way in which we can
I'm leaning towards combining them because separating commonalities
out into a third project is basically creating an SPI2. Also, most
of the stuff that would be pulled out is related to injection and
reflection which I don't think we want to expose as an API at this
point.
Jim
On Jun
[ http://issues.apache.org/jira/browse/TUSCANY-470?page=all ]
Raymond Feng closed TUSCANY-470:
Resolution: Invalid
If the property (open or normal) name doesn't contain the special character
'.', it works.
DataObject.getXXX(propertyName)
Potential trap in SCA web service entry point
-
Key: TUSCANY-482
URL: http://issues.apache.org/jira/browse/TUSCANY-482
Project: Tuscany
Type: Bug
Components: C++ SCA
Environment: all
Reporter: Ed Slattery
In
Jim Marino wrote:
I'm leaning towards combining them because separating commonalities out
into a third project is basically creating an SPI2. Also, most of the
stuff that would be pulled out is related to injection and reflection
which I don't think we want to expose as an API at this
We currently have versionincubating-M1/version in all our pom.xml
files. What do you think we should use now?
SNAPSHOT?
1.0-SNAPSHOT?
0.1-SNAPSHOT?
Any opinions?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
1.0-incubating-M2-SNAPSHOT
is probably the technical version number we should be using. It
specifically states we are working on the snapshot version
of 1.0-incubating-M2 which I assume will be the version we use when we
release M2.
Dan
On Tuesday June 20 2006 12:29 pm, Jean-Sebastien
yea sounds good except I'll abbreviate implementation to impl so
the package names are reasonable.
Jim
On Jun 20, 2006, at 9:25 AM, Jeremy Boynes wrote:
Jim Marino wrote:
I'm leaning towards combining them because separating
commonalities out
into a third project is basically creating an
Jim Marino wrote:
yea sounds good except I'll abbreviate implementation to impl so
the package names are reasonable.
I think impl would be confusing given its usage elsewhere (as the
package containing the impl of an api) - how about impltype ?
--
Jeremy
Jim Marino wrote:
In trying to eliminate reliance on core2 by container.java in the
sandbox and have it only rely on the extensibility SPI, it occurred to
me that this would mandate moving a lot of implementation classes from
core2 into SPI. I believe having container.java as a separate
Jeremy Boynes wrote:
I've removed the runtime modules from the build until we figure this
out - they should still work on their own if folks want to build an
assembly.
Thanks to a tip from Dan, I tried this with a build of the assembly
plugin from m2 trunk and the duplicate build issue was
[
http://issues.apache.org/jira/browse/TUSCANY-477?page=comments#action_12416955
]
Yang ZHONG commented on TUSCANY-477:
One has substitutionGroup referencing (which will fail since null is passed as
schemaLocation on purpose), the other one doesn't.
I
Jeremy Boynes wrote:
Any progress on this?
Jeremy Boynes wrote:
I have seen in a couple of offlist email discussions about prospective
committers but I am concerned that not all committers may be on them.
IIRC Ant had suggested we create a private or PPMC list for all
committers and I think
Not yet folks!
-- dims
On 6/20/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Jeremy Boynes wrote:
Any progress on this?
Jeremy Boynes wrote:
I have seen in a couple of offlist email discussions about prospective
committers but I am concerned that not all committers may be on them.
Davanum Srinivas wrote:
Not yet folks!
There's an issue for it:
http://issues.apache.org/jira/browse/INFRA-839
Geir has said he's on it (but hasn't assigned it yet).
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Hi Darius,
Welcom to Tuscany project. We can use help in many areas.
You can grab a JIRA and work on it if it is not grabbed by somene else. Once
done, follow the patch process that is documented on the website to submit
the patch.
Please don't hesitate to post any questions you might have on
Jim Marino wrote:
Which code base are you intending to use: the M1 which implements the
old .9 spec or the sandbox one which implements support for the new
recursive model, or both?
In terms of how to specifically improve the extensibility story, my
opinions have been embodied in the sandbox
Jean-Sebastien Delfino wrote:
- I was counting on the groovy container that you pointed me to
yesterday to understand better the new SPIs but I'm not able to build
it, the test cases fail with:
java.lang.NoSuchMethodError:
Given the initial example, I expect
true == documentRootType.getProperty(
implementation).getType().isSequence()
then it's possible to use public API (Sequence) to inspect the actual
instance.
I guess I can get info such as implementatio.java vs. implementation
xsi:type=...
--
Sincerely
Yang
[snip]
Elizabeth Delouise wrote:
More specifically, my question is whether or not the tuscany runtime
supports an Http-Get binding. I was told that it does not.
Tuscany currently supports two different implementations of the SCA web
service binding:
- on top of Axis2, and Axis2 supports
Some refactoring is necessary after adding the DAS/CommandGroup
---
Key: TUSCANY-483
URL: http://issues.apache.org/jira/browse/TUSCANY-483
Project: Tuscany
Type: Improvement
Components: Java DAS RDB
26 matches
Mail list logo
