You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2011/01/20 20:55:30 UTC
IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
I'm seeing some test fails in the latest svn code with an
IndexOutOfBoundsException in either
JavaInterfaceImpl.isAsyncServerOperation or MediatorImpl.copyInput.
Does anyone have some changes not completely checked in or know
anything that might be related?
...ant
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by Mike Edwards <mi...@gmail.com>.
On 20/01/2011 21:17, ant elder wrote:
> On Thu, Jan 20, 2011 at 9:10 PM, Scott Kurz<sc...@gmail.com> wrote:
>> I recreated that MediatorImpl.copyInput failure now... Maybe the
>> problem was that earlier I ran "offline" and had something stale in my
>> mvn repo???
>>
>> Anyway..looking into both problems now..
>>
>> What was a module you used to notice the 2nd problem with
>> JavaInterfaceImpl.isAsyncServerOperation?
>>
>
> One example is testing\itest\async-services
>
> ...ant
>
Scott,
Yes, Ant identifies cases that are still failing.
I suspect that your interface handling changes don't account properly for Java interfaces that have
the "async server" format, where a regular method like:
String someOperation( Int input )
is mapped to this:
void someOperationAsync( Int input, ResponseDispatch<String> response )
So far it looks like the type of the output parameter is being mapped incorrectly now - I see some
instances where the output parameter has a type of idl:input associated with it rather than
idl:output. The code that does this is a bit dense and I cannot pin it down yet.
Yours, Mike.
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by ant elder <an...@apache.org>.
On Thu, Jan 20, 2011 at 9:10 PM, Scott Kurz <sc...@gmail.com> wrote:
> I recreated that MediatorImpl.copyInput failure now... Maybe the
> problem was that earlier I ran "offline" and had something stale in my
> mvn repo???
>
> Anyway..looking into both problems now..
>
> What was a module you used to notice the 2nd problem with
> JavaInterfaceImpl.isAsyncServerOperation?
>
One example is testing\itest\async-services
...ant
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by Scott Kurz <sc...@gmail.com>.
I recreated that MediatorImpl.copyInput failure now... Maybe the
problem was that earlier I ran "offline" and had something stale in my
mvn repo???
Anyway..looking into both problems now..
What was a module you used to notice the 2nd problem with
JavaInterfaceImpl.isAsyncServerOperation?
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by ant elder <an...@apache.org>.
On Wed, Jan 26, 2011 at 2:41 PM, Florian MOGA <mo...@gmail.com> wrote:
> Regarding Maven, I did a complete build of Tuscany 2.0-beta2 RC1 with Maven
> 3 and I've been surprised to see the performance improvement. Beside that,
> you can use it with something like "-T 5C" (5 threads per core) and it does
> parallel builds where possible. All I had to do is to remove the
> <layout>legacy</layout> line for the Maven 1 Repo and it worked. It seems
> like we can make our poms both Maven 2 and Maven 3 compliant with minimal
> changes so we won't affect any of our users.
> I've also tried to run the itests from the root of the itest folder and
> Maven 3 complained about each and every pom that had incorrect parent
> relativePath (parents are not required anymore in Maven 3 but accepts them
> for backwards compatibility) so that will also help detecting our parent
> path problems.
> I'm going to proceed with the necessary changes in order to enable us to use
> Maven 2 or 3 without any changes. Let me know your thoughts on this. Is the
> ASF Hudson able to run Maven 3 builds? That could improve the build time...
Maven 3.0 is listed as one of the Maven versions in the Hudson config
so i guess its available. Anyway, +1 from me to update Tuscany to work
with both 2 and 3.
...ant
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by Florian MOGA <mo...@gmail.com>.
Regarding Maven, I did a complete build of Tuscany 2.0-beta2 RC1 with Maven
3 and I've been surprised to see the performance improvement. Beside that,
you can use it with something like "-T 5C" (5 threads per core) and it does
parallel builds where possible. All I had to do is to remove the
<layout>legacy</layout> line for the Maven 1 Repo and it worked. It seems
like we can make our poms both Maven 2 and Maven 3 compliant with minimal
changes so we won't affect any of our users.
I've also tried to run the itests from the root of the itest folder and
Maven 3 complained about each and every pom that had incorrect parent
relativePath (parents are not required anymore in Maven 3 but accepts them
for backwards compatibility) so that will also help detecting our parent
path problems.
I'm going to proceed with the necessary changes in order to enable us to use
Maven 2 or 3 without any changes. Let me know your thoughts on this. Is the
ASF Hudson able to run Maven 3 builds? That could improve the build time...
On Wed, Jan 26, 2011 at 12:04 PM, ant elder <an...@gmail.com> wrote:
> On Sat, Jan 22, 2011 at 2:25 PM, ant elder <an...@gmail.com> wrote:
>
> > The problem with doing that is that now the OASIS repo is also checked
> > for every artifact when building online which could add significantly
> > to the total build time.
> >
> > Looking at the current repository definitions i think most of those
> > are old historical ones which we don't even need anymore so i'm going
> > to have a go a cleaning them up. For the ones we do still need i think
> > we should change to define them in the modules that actually require
> > them instead of the top level pom.xml as that should avoid them being
> > queried for irrelevant artifacts.
> >
>
> I've just committed a change to do that and remove a lot of the other
> repository definitions. A full build from an empty repo is working for
> me and i'll kick off a hudson one to see how that goes. I had to do
> quite a lot of builds with an empty repo to find all the issues and it
> does seem faster a more reliable now without those. There's one
> module, testing\itest\ws\external-client, that still uses the java.net
> Maven 1.x Repository which is really slow and often times out, its
> required to get jaxws-rt 2.1.7 so it would be good to try to get the
> test working with a more recent jaxws-rt version that is in the
> central repo.
>
> ...ant
>
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by ant elder <an...@gmail.com>.
On Sat, Jan 22, 2011 at 2:25 PM, ant elder <an...@gmail.com> wrote:
> The problem with doing that is that now the OASIS repo is also checked
> for every artifact when building online which could add significantly
> to the total build time.
>
> Looking at the current repository definitions i think most of those
> are old historical ones which we don't even need anymore so i'm going
> to have a go a cleaning them up. For the ones we do still need i think
> we should change to define them in the modules that actually require
> them instead of the top level pom.xml as that should avoid them being
> queried for irrelevant artifacts.
>
I've just committed a change to do that and remove a lot of the other
repository definitions. A full build from an empty repo is working for
me and i'll kick off a hudson one to see how that goes. I had to do
quite a lot of builds with an empty repo to find all the issues and it
does seem faster a more reliable now without those. There's one
module, testing\itest\ws\external-client, that still uses the java.net
Maven 1.x Repository which is really slow and often times out, its
required to get jaxws-rt 2.1.7 so it would be good to try to get the
test working with a more recent jaxws-rt version that is in the
central repo.
...ant
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by ant elder <an...@gmail.com>.
On Sun, Jan 23, 2011 at 4:49 PM, Mike Edwards
<mi...@gmail.com> wrote:
> On 22/01/2011 14:25, ant elder wrote:
>>
>> The problem with doing that is that now the OASIS repo is also checked
>> for every artifact when building online which could add significantly
>> to the total build time.
>>
>> Looking at the current repository definitions i think most of those
>> are old historical ones which we don't even need anymore so i'm going
>> to have a go a cleaning them up. For the ones we do still need i think
>> we should change to define them in the modules that actually require
>> them instead of the top level pom.xml as that should avoid them being
>> queried for irrelevant artifacts.
>>
>> Besides all that why does that itest need to be using the oasis
>> version of the API's? The Tuscany version should work fine shouldn't
>> it (i tried it, it seems to)?
>>
>> ...ant
>>
> Ant,
>
> I think the boot is on the other foot.
>
> The SCA API jar is really one that belongs to OASIS - why does Tuscany have
> its own version of that jar, now that it is available from a Maven repo?
>
> I understand that Tuscany had to have its own API module historically, but
> why do that now?
>
>
> Yours, Mike.
>
>
I guess the main reasons in favour of using the Tuscany version is
that it gives us control more control over changes. It would also be
better if the OASIS version could be added to the Maven central
repository as maven people really dislike things not being in the
central repo.
Whatever happens I think that should be done as a conscious decision
by the project and if the decision is to use OASIS then change
everywhere consistently, having the Tuscany build mix the use of both
the OASIS and its own Tuscany version of the API classes doesn't make
a lot of sense, and in this itest case both these jars are now in the
classpath at the same time duplicating the classes.
...ant
SCA spec jar
Posted by Raymond Feng <en...@gmail.com>.
The previous thread title was confusing :-)
I prefer the jar from OASIS but the spec group needs to publish the jar/source/javadoc into the maven central instead of an OASIS repo. We know all the issues around private maven repos.
Raymond Feng
Sent from my iPhone
On Jan 23, 2011, at 8:49 AM, Mike Edwards <mi...@gmail.com> wrote:
> On 22/01/2011 14:25, ant elder wrote:
>>
>> The problem with doing that is that now the OASIS repo is also checked
>> for every artifact when building online which could add significantly
>> to the total build time.
>>
>> Looking at the current repository definitions i think most of those
>> are old historical ones which we don't even need anymore so i'm going
>> to have a go a cleaning them up. For the ones we do still need i think
>> we should change to define them in the modules that actually require
>> them instead of the top level pom.xml as that should avoid them being
>> queried for irrelevant artifacts.
>>
>> Besides all that why does that itest need to be using the oasis
>> version of the API's? The Tuscany version should work fine shouldn't
>> it (i tried it, it seems to)?
>>
>> ...ant
>>
> Ant,
>
> I think the boot is on the other foot.
>
> The SCA API jar is really one that belongs to OASIS - why does Tuscany have its own version of that jar, now that it is available from a Maven repo?
>
> I understand that Tuscany had to have its own API module historically, but why do that now?
>
>
> Yours, Mike.
>
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by Mike Edwards <mi...@gmail.com>.
On 22/01/2011 14:25, ant elder wrote:
>
> The problem with doing that is that now the OASIS repo is also checked
> for every artifact when building online which could add significantly
> to the total build time.
>
> Looking at the current repository definitions i think most of those
> are old historical ones which we don't even need anymore so i'm going
> to have a go a cleaning them up. For the ones we do still need i think
> we should change to define them in the modules that actually require
> them instead of the top level pom.xml as that should avoid them being
> queried for irrelevant artifacts.
>
> Besides all that why does that itest need to be using the oasis
> version of the API's? The Tuscany version should work fine shouldn't
> it (i tried it, it seems to)?
>
> ...ant
>
Ant,
I think the boot is on the other foot.
The SCA API jar is really one that belongs to OASIS - why does Tuscany have its own version of that
jar, now that it is available from a Maven repo?
I understand that Tuscany had to have its own API module historically, but why do that now?
Yours, Mike.
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by ant elder <an...@gmail.com>.
On Fri, Jan 21, 2011 at 2:39 PM, Mike Edwards
<mi...@gmail.com> wrote:
> On 21/01/2011 14:13, Scott Kurz wrote:
>>
>> I saw that too and manually installed it after finding an earlier
>> thread on this ML (too lazy to link).
>>
>> Got the JAR here:
>>
>>
>> http://tools.oasis-open.org/version-control/svn/sca-j/Release/org/oasis-open/sca/j/sca-caa-apis/1.1-CD04/sca-caa-apis-1.1-CD04.jar
>>
>> The earlier thread discussed things like if it couldn't be placed in
>> the central Maven repo... (apparently not??).
>>
> Folks,
>
> The simple answer is that it IS in a Maven repo - but an OASIS one rather
> than the central one.
>
> So the fix is to add this repo into the Tuscany top level POM, which I've
> just done.
>
>
The problem with doing that is that now the OASIS repo is also checked
for every artifact when building online which could add significantly
to the total build time.
Looking at the current repository definitions i think most of those
are old historical ones which we don't even need anymore so i'm going
to have a go a cleaning them up. For the ones we do still need i think
we should change to define them in the modules that actually require
them instead of the top level pom.xml as that should avoid them being
queried for irrelevant artifacts.
Besides all that why does that itest need to be using the oasis
version of the API's? The Tuscany version should work fine shouldn't
it (i tried it, it seems to)?
...ant
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by Mike Edwards <mi...@gmail.com>.
On 21/01/2011 14:13, Scott Kurz wrote:
> I saw that too and manually installed it after finding an earlier
> thread on this ML (too lazy to link).
>
> Got the JAR here:
>
> http://tools.oasis-open.org/version-control/svn/sca-j/Release/org/oasis-open/sca/j/sca-caa-apis/1.1-CD04/sca-caa-apis-1.1-CD04.jar
>
> The earlier thread discussed things like if it couldn't be placed in
> the central Maven repo... (apparently not??).
>
Folks,
The simple answer is that it IS in a Maven repo - but an OASIS one rather than the central one.
So the fix is to add this repo into the Tuscany top level POM, which I've just done.
Yours, Mike.
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by Scott Kurz <sc...@gmail.com>.
I saw that too and manually installed it after finding an earlier
thread on this ML (too lazy to link).
Got the JAR here:
http://tools.oasis-open.org/version-control/svn/sca-j/Release/org/oasis-open/sca/j/sca-caa-apis/1.1-CD04/sca-caa-apis-1.1-CD04.jar
The earlier thread discussed things like if it couldn't be placed in
the central Maven repo... (apparently not??).
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Jan 21, 2011 at 12:07 PM, Mike Edwards
<mi...@gmail.com> wrote:
> On 21/01/2011 11:07, Mike Edwards wrote:
>>
>> On 20/01/2011 23:29, ant elder wrote:
>>>
>>> On Thu, Jan 20, 2011 at 9:36 PM, Scott Kurz<sc...@gmail.com> wrote:
>>>>
>>>> I just committed what I hope is a fix in r1061531.
>>>>
>>>> It made the copyInput IndexOutOfBoundsException in
>>>> sample-implementation-extension go away... (will give some more
>>>> thought to whether this fix to interface-wsdl is the best solution).
>>>>
>>>> I can't run that async-services test yet.. I need to update my mvn
>>>> repo.. but I'm pretty confident my fix should work for that as well.
>>>>
>>>> That said..clearly my testing wasn't good enough if Mike's seeing
>>>> failures all over the place.. so I'm doing some more careful testing
>>>> now.
>>>>
>>>> Scott
>>>>
>>>
>>> Thats fixed all the IndexOutOfBoundsException for me. I do still get
>>> other test fails in
>>> testing\itest\ws\holder-ws-service-multiple-outputs and
>>> testing\itest\async-services
>>>
>>> ...ant
>>>
>> Folks,
>>
>> I think I have a fix for the async-services failures:
>>
>> for an interface with the async server format, the databinding applied to
>> the response parameter was
>> being set to IDL:INPUT when it should be IDL:OUTPUT - this is in
>> JavaInterfaceImpl.
>>
>> Changing this enables the async-services Itests to all pass.
>>
>> The holder-ws-service-multiple-outputs is a different problem I suspect.
>>
>> Note: Fixing this raises the question of whether async server interfaces
>> can have holders - and I
>> think the answer is "NO". I'll discuss that point separately on the list.
>>
>> Yours, Mike.
>>
>>
>>
> Fix committed at 1061775
>
> Yours, Mike.
>
I now get....
[INFO] ------------------------------------------------------------------------
[INFO] Error for project: Apache Tuscany SCA iTest Asynchronous Services (during
install)
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
Missing:
----------
1) org.oasis-open.sca.j:sca-caa-apis:jar:1.1-CD04
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.oasis-open.sca.j -DartifactId=sca-c
aa-apis -Dversion=1.1-CD04 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.oasis-open.sca.j -DartifactId=sca-caa
-apis -Dversion=1.1-CD04 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -Drepo
sitoryId=[id]
Path to dependency:
1) org.apache.tuscany.sca:itest-async-services:jar:2.0-SNAPSHOT
2) org.oasis-open.sca.j:sca-caa-apis:jar:1.1-CD04
----------
1 required artifact is missing.
for artifact:
org.apache.tuscany.sca:itest-async-services:jar:2.0-SNAPSHOT
from the specified remote repositories:
apache.snapshots (http://repository.apache.org/snapshots),
central (http://repo1.maven.org/maven2),
indiana (http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/),
java.net (http://download.java.net/maven/1),
intalio.org (http://www.intalio.org/public/maven2),
tuscany.repo (http://svn.apache.org/repos/asf/tuscany/maven),
maven.central (http://repo2.maven.org/maven2),
apache.incubator (http://people.apache.org/repo/m2-incubating-repository),
java.net2 (http://download.java.net/maven/2),
apache.ws.zone (http://ws.zones.apache.org/repository2),
osuosl.org (http://ftp.osuosl.org/pub/eclipse/tools/emf/maven2)
Any ideas?
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by Mike Edwards <mi...@gmail.com>.
On 21/01/2011 11:07, Mike Edwards wrote:
> On 20/01/2011 23:29, ant elder wrote:
>> On Thu, Jan 20, 2011 at 9:36 PM, Scott Kurz<sc...@gmail.com> wrote:
>>> I just committed what I hope is a fix in r1061531.
>>>
>>> It made the copyInput IndexOutOfBoundsException in
>>> sample-implementation-extension go away... (will give some more
>>> thought to whether this fix to interface-wsdl is the best solution).
>>>
>>> I can't run that async-services test yet.. I need to update my mvn
>>> repo.. but I'm pretty confident my fix should work for that as well.
>>>
>>> That said..clearly my testing wasn't good enough if Mike's seeing
>>> failures all over the place.. so I'm doing some more careful testing
>>> now.
>>>
>>> Scott
>>>
>>
>> Thats fixed all the IndexOutOfBoundsException for me. I do still get
>> other test fails in
>> testing\itest\ws\holder-ws-service-multiple-outputs and
>> testing\itest\async-services
>>
>> ...ant
>>
> Folks,
>
> I think I have a fix for the async-services failures:
>
> for an interface with the async server format, the databinding applied to the response parameter was
> being set to IDL:INPUT when it should be IDL:OUTPUT - this is in JavaInterfaceImpl.
>
> Changing this enables the async-services Itests to all pass.
>
> The holder-ws-service-multiple-outputs is a different problem I suspect.
>
> Note: Fixing this raises the question of whether async server interfaces can have holders - and I
> think the answer is "NO". I'll discuss that point separately on the list.
>
> Yours, Mike.
>
>
>
Fix committed at 1061775
Yours, Mike.
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Jan 21, 2011 at 11:07 AM, Mike Edwards
<mi...@gmail.com> wrote:
> On 20/01/2011 23:29, ant elder wrote:
>>
>> On Thu, Jan 20, 2011 at 9:36 PM, Scott Kurz<sc...@gmail.com> wrote:
>>>
>>> I just committed what I hope is a fix in r1061531.
>>>
>>> It made the copyInput IndexOutOfBoundsException in
>>> sample-implementation-extension go away... (will give some more
>>> thought to whether this fix to interface-wsdl is the best solution).
>>>
>>> I can't run that async-services test yet.. I need to update my mvn
>>> repo.. but I'm pretty confident my fix should work for that as well.
>>>
>>> That said..clearly my testing wasn't good enough if Mike's seeing
>>> failures all over the place.. so I'm doing some more careful testing
>>> now.
>>>
>>> Scott
>>>
>>
>> Thats fixed all the IndexOutOfBoundsException for me. I do still get
>> other test fails in
>> testing\itest\ws\holder-ws-service-multiple-outputs and
>> testing\itest\async-services
>>
>> ...ant
>>
> Folks,
>
> I think I have a fix for the async-services failures:
>
> for an interface with the async server format, the databinding applied to
> the response parameter was being set to IDL:INPUT when it should be
> IDL:OUTPUT - this is in JavaInterfaceImpl.
>
> Changing this enables the async-services Itests to all pass.
>
> The holder-ws-service-multiple-outputs is a different problem I suspect.
>
> Note: Fixing this raises the question of whether async server interfaces can
> have holders - and I think the answer is "NO". I'll discuss that point
> separately on the list.
>
> Yours, Mike.
>
>
>
>
Scott's commit at 1061329 says that there is still work to do on bare
so I'll go ahead an @Ignore the bare test, which is the
holder-ws-service-multiple-outputs that fails for me while he looks at
it.
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by Mike Edwards <mi...@gmail.com>.
On 20/01/2011 23:29, ant elder wrote:
> On Thu, Jan 20, 2011 at 9:36 PM, Scott Kurz<sc...@gmail.com> wrote:
>> I just committed what I hope is a fix in r1061531.
>>
>> It made the copyInput IndexOutOfBoundsException in
>> sample-implementation-extension go away... (will give some more
>> thought to whether this fix to interface-wsdl is the best solution).
>>
>> I can't run that async-services test yet.. I need to update my mvn
>> repo.. but I'm pretty confident my fix should work for that as well.
>>
>> That said..clearly my testing wasn't good enough if Mike's seeing
>> failures all over the place.. so I'm doing some more careful testing
>> now.
>>
>> Scott
>>
>
> Thats fixed all the IndexOutOfBoundsException for me. I do still get
> other test fails in
> testing\itest\ws\holder-ws-service-multiple-outputs and
> testing\itest\async-services
>
> ...ant
>
Folks,
I think I have a fix for the async-services failures:
for an interface with the async server format, the databinding applied to the response parameter was
being set to IDL:INPUT when it should be IDL:OUTPUT - this is in JavaInterfaceImpl.
Changing this enables the async-services Itests to all pass.
The holder-ws-service-multiple-outputs is a different problem I suspect.
Note: Fixing this raises the question of whether async server interfaces can have holders - and I
think the answer is "NO". I'll discuss that point separately on the list.
Yours, Mike.
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by ant elder <an...@gmail.com>.
On Thu, Jan 20, 2011 at 9:36 PM, Scott Kurz <sc...@gmail.com> wrote:
> I just committed what I hope is a fix in r1061531.
>
> It made the copyInput IndexOutOfBoundsException in
> sample-implementation-extension go away... (will give some more
> thought to whether this fix to interface-wsdl is the best solution).
>
> I can't run that async-services test yet.. I need to update my mvn
> repo.. but I'm pretty confident my fix should work for that as well.
>
> That said..clearly my testing wasn't good enough if Mike's seeing
> failures all over the place.. so I'm doing some more careful testing
> now.
>
> Scott
>
Thats fixed all the IndexOutOfBoundsException for me. I do still get
other test fails in
testing\itest\ws\holder-ws-service-multiple-outputs and
testing\itest\async-services
...ant
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by Scott Kurz <sc...@gmail.com>.
I just committed what I hope is a fix in r1061531.
It made the copyInput IndexOutOfBoundsException in
sample-implementation-extension go away... (will give some more
thought to whether this fix to interface-wsdl is the best solution).
I can't run that async-services test yet.. I need to update my mvn
repo.. but I'm pretty confident my fix should work for that as well.
That said..clearly my testing wasn't good enough if Mike's seeing
failures all over the place.. so I'm doing some more careful testing
now.
Scott
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by Mike Edwards <mi...@gmail.com>.
On 20/01/2011 21:05, Scott Kurz wrote:
> I see the problem in JavaInterfaceImpl.isAsyncServerOperation. The
> output type will be an empty list in this case, so I can tweak the
> check.
>
> The issue with MediatorImpl concerns me more since I ran the same
> tests and didn't notice that problem. One thing I noticed during
> various tests I ran was that sometimes I went through
> MediatorImpl.copyXXXX and sometimes I didn't, when running with the
> default binding. I don't completely understand why.
>
Scott,
I see failures all over the place with this index out of bounds problem - grateful if you can upload
a fix soon.
Yours, Mike.
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by Scott Kurz <sc...@gmail.com>.
I see the problem in JavaInterfaceImpl.isAsyncServerOperation. The
output type will be an empty list in this case, so I can tweak the
check.
The issue with MediatorImpl concerns me more since I ran the same
tests and didn't notice that problem. One thing I noticed during
various tests I ran was that sometimes I went through
MediatorImpl.copyXXXX and sometimes I didn't, when running with the
default binding. I don't completely understand why.
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by ant elder <an...@apache.org>.
On Thu, Jan 20, 2011 at 8:38 PM, Scott Kurz <sc...@gmail.com> wrote:
> That's probably my change for TUSCANY-3819.
>
> What are you seeing ?
>
> I should say that there are 10 tests in
> itest/ws/holder-ws-service-multiple-outputs that I still expect to
> fail (am hoping to address that shortly).
>
> Scott
>
I think there may be two separate bugs causing different test fails,
one in MediatorImpl.copyInput and the other in
JavaInterfaceImpl.isAsyncServerOperation. An example of the
MediatorImpl.copyInput one is
samples\extending-tuscany\implementation-sample which gives this
exception:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sample.impl.SampleJavaInvoker.invoke(SampleJavaInvoker.java:45)
at org.apache.tuscany.sca.binding.sca.provider.SCABindingLocalInvocationInterceptor.invoke(SCABindingLocalInvocationInterce
tor.java:49)
at org.apache.tuscany.sca.core.invocation.InterceptorAsyncImpl.invoke(InterceptorAsyncImpl.java:58)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:322)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:278)
at org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:125)
at org.apache.tuscany.sca.core.invocation.impl.AsyncJDKInvocationHandler.doInvokeSync(AsyncJDKInvocationHandler.java:239)
at org.apache.tuscany.sca.core.invocation.impl.AsyncJDKInvocationHandler.invoke(AsyncJDKInvocationHandler.java:161)
at $Proxy12.wello(Unknown Source)
at sample.impl.RunTestCase.wello(RunTestCase.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at org.apache.tuscany.sca.databinding.impl.MediatorImpl.copyInput(MediatorImpl.java:565)
at org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.processRequest(SCABindingInvoker.java:84)
at org.apache.tuscany.sca.core.invocation.InterceptorAsyncImpl.invoke(InterceptorAsyncImpl.java:57)
at org.apache.tuscany.sca.core.invocation.RuntimeInvoker.invoke(RuntimeInvoker.java:125)
at org.apache.tuscany.sca.core.invocation.RuntimeInvoker.invoke(RuntimeInvoker.java:108)
at org.apache.tuscany.sca.core.invocation.RuntimeInvoker.invoke(RuntimeInvoker.java:97)
at org.apache.tuscany.sca.core.assembly.impl.RuntimeEndpointReferenceImpl.invoke(RuntimeEndpointReferenceImpl.java:243)
at sample.impl.SampleWSDLProxy.call(SampleWSDLProxy.java:64)
at sample.ClientTest.wello(ClientTest.java:61)
... 42 more
Re: IndexOutOfBoundsException in MediatorImpl.copyInput and JavaInterfaceImpl.isAsyncServerOperation
Posted by Scott Kurz <sc...@gmail.com>.
That's probably my change for TUSCANY-3819.
What are you seeing ?
I should say that there are 10 tests in
itest/ws/holder-ws-service-multiple-outputs that I still expect to
fail (am hoping to address that shortly).
Scott