Re: Getting "RuntimeException: Can't find input stream in message" while invoking a remote web service (with JBoss AS 6.0 GA)

2011-01-19 Thread Sergey Beryozkin 
Christian has fixed it in 2.3.2 (being voted for now), most likely the
server is sending an HTTP error status, with no response body...

Cheers, Sergey

On Wed, Jan 19, 2011 at 3:21 AM, cxfuser71  wrote:

>
> Hello All,
> I am using JBoss 6.0.GA release which comes with CXF webservice stack
> (version 2.3.1).
> I have a ws-client which resides in a jar under  EAR/lib directory of JBoss
> deployment.
> I am trying to invoke a remote web service (ListProperties() api) and
> getting following error.
> The WSDL address is valid and I can access the WSDL using browser without
> any problem.
>
> Can anyone please help me to investigate further?
>
> Thanks in advance,
>
> ===
>
> 19:08:20,449 INFO
> [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] Creating
> Service 
> {http://www.towersoft.com/schema/webservice/trim2/}Enginefrom
>  WSDL:
> http://rclient114.cup.hp.com:80/trimws/trim.asmx?WSDL
> 19:08:22,424 WARN  [org.apache.cxf.phase.PhaseInterceptorChain] Interceptor
> for
> {
> http://www.towersoft.com/schema/webservice/trim2/}Engine#{http://www.towersoft.com/
> schema/webservice/trim2/}ListPropertieshas
>  thrown exception, unwinding now:
> java.lang.RuntimeException: Can't find input stream in message
>at
>
> org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:116)
> [:2.3.1]
>at
>
> org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:60)
> [:2.3.1]
>at
>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> [:2.3.1]
>at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:755)
> [:2.3.1]
>at
>
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2330)
> [:2.3.1]
>at
>
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2192)
> [:2.3.1]
>at
>
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:2036)
> [:2.3.1]
>at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> [:2.3.1]
>at
> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:696)
> [:2.3.1]
>at
>
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> [:2.3.1]
>at
>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
> [:2.3.1]
>at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516)
> [:2.3.1]
>at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
> [:2.3.1]
>at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
> [:2.3.1]
>at
> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> [:2.3.1]
>at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> [:2.3.1]
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Getting-RuntimeException-Can-t-find-input-stream-in-message-while-invoking-a-remote-web-service-with-tp3347211p3347211.html
> Sent from the cxf-issues mailing list archive at Nabble.com.
>

Postponing or blocking message delivery from interceptor

2011-01-19 Thread Dennis Sosnoski 
I've verified that the current WS-RM code only implements transmit
handling (retry until acknowledged). A correct WS-RM implementation also
requires receive handling, to postpone the delivery of messages received
out of order when InOrder delivery assurance is used, and to block the
delivery of duplicate messages when AtMostOnce or ExactlyOnce is used.

In order to implement the receive handling, I need to be able to
short-circuit the processing of an in-bound message in an interceptor so
that no further processing is done at this time but the appropriate
transport response goes back to the sender (such as an HTTP 200 code). I
also need to be able to later resume processing of an in-bound message
from the point it left off. How can I best do this in CXF?

Thanks,

  - Dennis

-- 

Dennis M. Sosnoski
Java SOA and Web Services Consulting 
Axis2/CXF/Metro SOA and Web Services Training

Web Services Jump-Start

Promised test case for MTOM-related hangs

2011-01-19 Thread Benson Margulies 
Ian has cooked up test case for our woes with with wierd timeouts with
MTOM. Let us know if we can help further.

https://issues.apache.org/jira/browse/CXF-3259

Re: Postponing or blocking message delivery from interceptor

2011-01-19 Thread Daniel Kulp 
On Wednesday 19 January 2011 5:24:58 am Dennis Sosnoski wrote:
> I've verified that the current WS-RM code only implements transmit
> handling (retry until acknowledged). A correct WS-RM implementation also
> requires receive handling, to postpone the delivery of messages received
> out of order when InOrder delivery assurance is used, and to block the
> delivery of duplicate messages when AtMostOnce or ExactlyOnce is used.
> 
> In order to implement the receive handling, I need to be able to
> short-circuit the processing of an in-bound message in an interceptor so
> that no further processing is done at this time but the appropriate
> transport response goes back to the sender (such as an HTTP 200 code). 

Take a look at the OneWayInInterceptor for this.   Basically, it calls back 
into the destination with basically and empty message to notify the 
destination that we're "done" with this.

> I
> also need to be able to later resume processing of an in-bound message
> from the point it left off. How can I best do this in CXF?

Also look at the OneWayInInterceptor.  :-)You can just pause the chain and 
store the chain someplace.  When ready, restart it.   

-- 
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog

Re: Promised test case for MTOM-related hangs

2011-01-19 Thread Daniel Kulp 
On Wednesday 19 January 2011 1:56:35 pm Benson Margulies wrote:
> Ian has cooked up test case for our woes with with wierd timeouts with
> MTOM. Let us know if we can help further.
> 
> https://issues.apache.org/jira/browse/CXF-3259

The client isn't closing the streams.   If you do:

 DataHandler dh = d.getContentBlob("bogusDocID", "BogusBlobID");
 dh.getInputStream().close();

then it runs to completion.   Basically, the server has tried to send some 
data back to the client.  In your case, the 2048 bytes likely fits into the 
socket buffer so from the server sides point of view, data was sent.  However, 
the HTTPUrlConnection on the client side hasn't read all the data.   Thus, the 
client side cannot reuse the connection and creates more connections.   
Eventually, it runs out of file handles and thread pools and such.  (example:  
call "ulimit -n 256" first.  Dies pretty fast)Also, on the server side, 
the connections do look idle.  All data was sent to the client, but no furthur 
requests have come in (since the client cannot reuse the connection) so it 
closes them.

Basically, if you don't close streams, all hell can break lose.  :-)

-- 
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog

Re: [VOTE] Apache CXF 2.3.2

2011-01-19 Thread Jim Ma 
I have to vote -1 for this release.
The new changes in tagged CXF 2.3.2  introduced several JEE6 TCK
regression failures . I am looking for a quick fix for these failures.

Jim

On Wed, Jan 19, 2011 at 8:28 AM, Eric Johnson  wrote:
> +1
>
> On Tue, Jan 18, 2011 at 6:31 PM, Christian Schneider
>  wrote:
>> +1
>>
>> Christian
>>
>>
>> Am 18.01.2011 05:26, schrieb Daniel Kulp:
>>>
>>> We've had a busy 8 weeks or so despite the holidays.   We've managed to
>>> fix over 75 JIRA issues since 2.3.1 which is quite remarkable .  This also
>>> fixes a bunch of OSGi related issues that are needed for
>>> Camel and ServiceMix.
>>>
>>> Note:  this vote also includes a release of the cxf-xjc-utils to fix a
>>> bunch of issues that were resolved there.
>>>
>>>
>>> List of issues:
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315921&styleName=Text&projectId=12310511&Create=Create
>>>
>>> The Maven staging areas are at:
>>> https://repository.apache.org/content/repositories/orgapachecxf-041/
>>> https://repository.apache.org/content/repositories/orgapachecxf-042/
>>>
>>> The distributions are in:
>>>
>>> https://repository.apache.org/content/repositories/orgapachecxf-042/org/apache/cxf/apache-cxf/2.3.2/
>>>
>>> This release is tagged at:
>>> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.2
>>> http://svn.apache.org/repos/asf/cxf/xjc-utils/tags/xjc-utils-2.3.2/
>>>
>>> The vote will be open for 72 hours.
>>>
>>> Here is my +1.
>>>
>>>
>>>
>>
>> --
>> 
>> http://www.liquid-reality.de
>>
>>
>
>
>
> --
> Principle Technical Writer
> Phone (781) 280-4174
> Skype finnmccumial
> E-Mail emjohn...@fusesource.com
> Blog http://documentingit.blogspot.com/
>

Re: [VOTE] Apache CXF 2.3.2

2011-01-19 Thread Willem Jiang 
Maybe we can consider to release XJC 2.3.2 as it doesn't relate to TCK 
failures. And we don't need to cut new version of XJC 2.3.2 again.


Can we start a new vote for CXF XJC 2.3.2 ?

Willem
On 1/20/11 11:02 AM, Jim Ma wrote:

I have to vote -1 for this release.
The new changes in tagged CXF 2.3.2  introduced several JEE6 TCK
regression failures . I am looking for a quick fix for these failures.

Jim

On Wed, Jan 19, 2011 at 8:28 AM, Eric Johnson  wrote:

+1

On Tue, Jan 18, 2011 at 6:31 PM, Christian Schneider
  wrote:

+1

Christian


Am 18.01.2011 05:26, schrieb Daniel Kulp:


We've had a busy 8 weeks or so despite the holidays.   We've managed to
fix over 75 JIRA issues since 2.3.1 which is quite remarkable .  This also
fixes a bunch of OSGi related issues that are needed for
Camel and ServiceMix.

Note:  this vote also includes a release of the cxf-xjc-utils to fix a
bunch of issues that were resolved there.


List of issues:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315921&styleName=Text&projectId=12310511&Create=Create

The Maven staging areas are at:
https://repository.apache.org/content/repositories/orgapachecxf-041/
https://repository.apache.org/content/repositories/orgapachecxf-042/

The distributions are in:

https://repository.apache.org/content/repositories/orgapachecxf-042/org/apache/cxf/apache-cxf/2.3.2/

This release is tagged at:
http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.2
http://svn.apache.org/repos/asf/cxf/xjc-utils/tags/xjc-utils-2.3.2/

The vote will be open for 72 hours.

Here is my +1.





--

http://www.liquid-reality.de






--
Principle Technical Writer
Phone (781) 280-4174
Skype finnmccumial
E-Mail emjohn...@fusesource.com
Blog http://documentingit.blogspot.com/






--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
 http://jnn.javaeye.com (Chinese)
Twitter: willemjiang

Re: [VOTE] Apache CXF 2.3.2

2011-01-19 Thread Glen Mazza 
I don't think a new vote is necessary, because as stated the vote covers 
both portions.  So everyone has voted +1 and +1 up to Jim.


To be valid, a veto must have a justifiable reason, and Jim certainly 
does have one for CXF 2.3.2 but not CXF XJC 2.3.2, so the latter can 
still proceed (if desirable).  I would very much like to get CXF XJC 
2.3.2 fixed so I don't have to keep taking out the JAXB 2.2 libraries 
from my JDK when I try to make a build.  That said, I suspect Dan 
wouldn't want to release one without the other, it's just that a second 
vote isn't needed IMO.


Glen

On 19.01.2011 22:37, Willem Jiang wrote:
Maybe we can consider to release XJC 2.3.2 as it doesn't relate to TCK 
failures. And we don't need to cut new version of XJC 2.3.2 again.


Can we start a new vote for CXF XJC 2.3.2 ?

Willem
On 1/20/11 11:02 AM, Jim Ma wrote:

I have to vote -1 for this release.
The new changes in tagged CXF 2.3.2  introduced several JEE6 TCK
regression failures . I am looking for a quick fix for these failures.

Jim

On Wed, Jan 19, 2011 at 8:28 AM, Eric 
Johnson  wrote:

+1

On Tue, Jan 18, 2011 at 6:31 PM, Christian Schneider
  wrote:

+1

Christian


Am 18.01.2011 05:26, schrieb Daniel Kulp:


We've had a busy 8 weeks or so despite the holidays.   We've 
managed to
fix over 75 JIRA issues since 2.3.1 which is quite remarkable .  
This also

fixes a bunch of OSGi related issues that are needed for
Camel and ServiceMix.

Note:  this vote also includes a release of the cxf-xjc-utils to 
fix a

bunch of issues that were resolved there.


List of issues:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315921&styleName=Text&projectId=12310511&Create=Create 



The Maven staging areas are at:
https://repository.apache.org/content/repositories/orgapachecxf-041/
https://repository.apache.org/content/repositories/orgapachecxf-042/

The distributions are in:

https://repository.apache.org/content/repositories/orgapachecxf-042/org/apache/cxf/apache-cxf/2.3.2/ 



This release is tagged at:
http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.2
http://svn.apache.org/repos/asf/cxf/xjc-utils/tags/xjc-utils-2.3.2/

The vote will be open for 72 hours.

Here is my +1.





--

http://www.liquid-reality.de






--
Principle Technical Writer
Phone (781) 280-4174
Skype finnmccumial
E-Mail emjohn...@fusesource.com
Blog http://documentingit.blogspot.com/

Re: [VOTE] Apache CXF 2.3.2

2011-01-19 Thread Daniel Kulp 

I want to give Jim a bit more time to investigate what is causing the 
failures.  I chatted with him a bit on IRC and I'm not exactly sure how the 
test is SUPPOSED to work at all so it's hard to say what is going on.

THAT said, -1's on release votes are not a veto.  Thus, as release manager, 
it's my discretion as to how to handle the -1.   My gut feeling, right now, 
would be to release 2.3.2 "as is" as the standalone JAX-WS TCK does pass and 
thus all of OUR claims are OK.   Once we get a handle on the J2EE level 
things, we can quickly spin a 2.3.3.   I really have no issues with a "release 
often" approach.

That said, I do want to give Jim a little more time to look into it.  Since 
there is still 20ish hours left on the vote, it's not something I'll commit to 
either way RIGHT NOW.   It may end being something JBoss can work around and 
we won't need to worry about it. (that has happened a couple times in the 
past)   

Dan


On Wednesday 19 January 2011 10:59:03 pm Glen Mazza wrote:
> I don't think a new vote is necessary, because as stated the vote covers
> both portions.  So everyone has voted +1 and +1 up to Jim.
> 
> To be valid, a veto must have a justifiable reason, and Jim certainly
> does have one for CXF 2.3.2 but not CXF XJC 2.3.2, so the latter can
> still proceed (if desirable).  I would very much like to get CXF XJC
> 2.3.2 fixed so I don't have to keep taking out the JAXB 2.2 libraries
> from my JDK when I try to make a build.  That said, I suspect Dan
> wouldn't want to release one without the other, it's just that a second
> vote isn't needed IMO.
> 
> Glen
> 
> On 19.01.2011 22:37, Willem Jiang wrote:
> > Maybe we can consider to release XJC 2.3.2 as it doesn't relate to TCK
> > failures. And we don't need to cut new version of XJC 2.3.2 again.
> > 
> > Can we start a new vote for CXF XJC 2.3.2 ?
> > 
> > Willem
> > 
> > On 1/20/11 11:02 AM, Jim Ma wrote:
> >> I have to vote -1 for this release.
> >> The new changes in tagged CXF 2.3.2  introduced several JEE6 TCK
> >> regression failures . I am looking for a quick fix for these failures.
> >> 
> >> Jim
> >> 
> >> On Wed, Jan 19, 2011 at 8:28 AM, Eric
> >> 
> >> Johnson  wrote:
> >>> +1
> >>> 
> >>> On Tue, Jan 18, 2011 at 6:31 PM, Christian Schneider
> >>> 
> >>>   wrote:
>  +1
>  
>  Christian
>  
>  Am 18.01.2011 05:26, schrieb Daniel Kulp:
> > We've had a busy 8 weeks or so despite the holidays.   We've
> > managed to
> > fix over 75 JIRA issues since 2.3.1 which is quite remarkable .
> > This also
> > fixes a bunch of OSGi related issues that are needed for
> > Camel and ServiceMix.
> > 
> > Note:  this vote also includes a release of the cxf-xjc-utils to
> > fix a
> > bunch of issues that were resolved there.
> > 
> > 
> > List of issues:
> > 
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=123159
> > 21&styleName=Text&projectId=12310511&Create=Create
> > 
> > 
> > The Maven staging areas are at:
> > https://repository.apache.org/content/repositories/orgapachecxf-041/
> > https://repository.apache.org/content/repositories/orgapachecxf-042/
> > 
> > The distributions are in:
> > 
> > https://repository.apache.org/content/repositories/orgapachecxf-042/o
> > rg/apache/cxf/apache-cxf/2.3.2/
> > 
> > 
> > This release is tagged at:
> > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.2
> > http://svn.apache.org/repos/asf/cxf/xjc-utils/tags/xjc-utils-2.3.2/
> > 
> > The vote will be open for 72 hours.
> > 
> > Here is my +1.

-- 
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog

Re: Postponing or blocking message delivery from interceptor

2011-01-19 Thread Dennis Sosnoski 
On 01/20/2011 08:19 AM, Daniel Kulp wrote:
> On Wednesday 19 January 2011 5:24:58 am Dennis Sosnoski wrote:
>   
>> ...
>>
>> In order to implement the receive handling, I need to be able to
>> short-circuit the processing of an in-bound message in an interceptor so
>> that no further processing is done at this time but the appropriate
>> transport response goes back to the sender (such as an HTTP 200 code). 
>> 
> Take a look at the OneWayInInterceptor for this.   Basically, it calls back 
> into the destination with basically and empty message to notify the 
> destination that we're "done" with this.
>   

Do you mean org.apache.cxf.interceptor.OneWayProcessorInterceptor? That
was the closest I could find to OneWayInInterceptor, which uses this
code to send the empty message back:

Message partial = createMessage(message.getExchange());
partial.remove(Message.CONTENT_TYPE);
partial.setExchange(message.getExchange());
Conduit conduit = message.getExchange().getDestination()
.getBackChannel(message, null, null);
if (conduit != null) {
//for a one-way, the back channel could be
//null if it knows it cannot send anything.
conduit.prepare(partial);
conduit.close(partial);
}

The WS-RM code does implement duplicate message checks if AtMostOnce is
specified (in org.apache.cxf.ws.rm.DestinationSequence), in which case
it throws an exception that goes all the way up the call stack to
PhaseInterceptorChain. I'd think that would result in a Fault response
to the client when using two-way calls, though - so it really needs to
be handled using the above type of approach instead, right?

Incidentally, the DestinationSequence code logs a duplicate message at
SEVERE level. Shouldn't this really be INFO level, for an event which is
interesting but not really any kind of error?


>> I
>> also need to be able to later resume processing of an in-bound message
>> from the point it left off. How can I best do this in CXF?
>> 
> Also look at the OneWayInInterceptor.  :-)You can just pause the chain 
> and 
> store the chain someplace.  When ready, restart it.   
>   

Yes, I see. Thanks for the pointer!

  - Dennis