On Tue, Sep 14, 2010 at 4:00 PM, ant elder <[email protected]> wrote: > On Tue, Sep 14, 2010 at 3:41 PM, Simon Laws <[email protected]> wrote: >> On Fri, Sep 10, 2010 at 9:52 AM, Simon Laws <[email protected]> >> wrote: >>>> >>>> Yes i see the same for some days now. Its quite random, rerunning the >>>> tests over and over with mvn or eclipse and sometimes it works fine >>>> other times it gets the NPE with the head invoker null. >>>> >>>> Not certain but i think it started happening after the jsonp binding >>>> was changed to delegate to the http binding runtime. >>>> >>>> ...ant >>>> >>> >>> Interesting. No idea if this has any relevance but when that did >>> happen I did get this strange dependency error relating to >>> jsonp-runtime depending on something like host-http (looking back >>> through mails now). Which I couldn't satisfactorily explain. I think >>> you fixed it by adding the dependency but it did look a bit odd at the >>> time. >>> >>> Simon >>> >>> -- >>> Apache Tuscany committer: tuscany.apache.org >>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com >>> >> >> I'm making some progress on this. The NPE is actually caused by this >> line in the HTTPBindingProviderFactory... >> >> public ReferenceBindingProvider >> createReferenceBindingProvider(RuntimeEndpointReference >> endpointReference) { >> // Binding HTTP is currently NOT supporting References >> return null; >> } >> >> The reason the problem is random is that the JSONP model sometimes >> picks up the HTPPBindingProviderFactory and sometimes picks up the >> JSONPBindingProviderFactory. >> > > Terrific debugging skills :) I'd wasted away more than a few minutes > trying to workout what was going wrong without any success. > >> What was the actual intention re. the aggregation of JSONP and HTTP bindings? >> > > We need to decide if reusing the one runtime module across multiple > binding types is something we really want to do and then if so finish > it properly. I'm happy to do/help with the finishing it if that is the > way we decide to go. > > It does seem like a good thing to be able to reuse a lot of the code > that would be common across these type of bindings that are using http > transport, so i guess i'd favour continuing with the reusing path but > i can see there are pros and cons. > > ...ant >
I just checked in a short term change for the NPE at r996954. I ranked the binding provider factories so the correct one is picked up every time. Ultimately, as said previously, we need to decide to either merge with the HTTP binding or not. If we're going to do that then HTTP needs to support references and a JSONP wire format. There doesn't seem to be a particular downside as the user can still specify <binding.jsonp/> if they want and the upside is that we get code better re-use. So I think we should look at fixing up the HTTP binding and removing the JSONP implementation module. It would be useful to have some kind of HTTP reference support anyhow even though there are some tricky issues in a full solution. Other thoughts? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
