I think this is what David told me when I first made the Jetty impl is
the default for our http service.
Well, I think 1-2 MB added to OpenEJB is not so much cost to have a
production stable binaries. And We can make two set of binaries for
end users, 1) w/o Jetty for playing and testing 2) With Jetty for more
real applications, and for people compiling the source code we can
provide a JVM property to build openejb with or w/o Jetty.
On Fri, Aug 8, 2008 at 9:07 PM, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> I'd like to get rid our our implementation. The only real drawback I see is
> the distribution will get 1-2MB bigger.
>
> -dain
>
> On Aug 7, 2008, at 7:48 PM, Karan Malhi wrote:
>
>> I am bringing this thread to the dev list. David made an interesting
>> comment
>> (see below) about Jetty (it should be used in production instead of our
>> Http
>> Imp). This got me thinking as to why were we using our impl if Jetty was
>> already available. I was not sure about this and was going to post a
>> question on this. Incidentally during a chat with Dain , he mentioned that
>> we should mainly start using Jetty as our Http impl.
>>
>> I am thinking, if the D's prefer Jetty, is there a reason we are still
>> using our Http Impl?
>>
>>
>> On Thu, Aug 7, 2008 at 7:54 PM, David Blevins
>> <[EMAIL PROTECTED]>wrote:
>>
>>>
>>> On Aug 7, 2008, at 5:34 AM, Karan Malhi wrote:
>>>
>>> You are not doing anything wrong (I was able to reproduce this scenario
>>> ).
>>>>
>>>> This is a bug which does not handle the situation when the web service
>>>> returns back large results. Adding Jetty to the classpath would fix the
>>>> issue, however if you do not want to add Jetty to the classpath, then
>>>> you
>>>> would need to wait a bit before this bug is fixed.
>>>>
>>>
>>> I'd strongly recommend adding the jetty library. Our impl is really for
>>> simple testing, anything heavy-duty should use the jetty transport. If
>>> you
>>> just add the jetty jars to the classpath (or an openejb/lib/ dir) we will
>>> automatically detect jetty and hook everything up for you automagically.
>>>
>>> -David
>>>
>>> On Tue, Aug 5, 2008 at 5:30 PM, hofmanndavid <[EMAIL PROTECTED]>
>>>>
>>>> wrote:
>>>>
>>>>
>>>>> I have a webservice exposed in a embedded openejb, from another
>>>>> computer
>>>>> I
>>>>> am
>>>>> calling that webservice
>>>>>
>>>>> the scenario is this:
>>>>> I am calling a method signature like this
>>>>> String myMethod(String arg)
>>>>>
>>>>> if the answer of myMethod is too long it shows the next exception, if
>>>>> it
>>>>> is
>>>>> not too long, it just works, the exception does not come from the
>>>>> implementation of the method of the webservice, it raised in the cilent
>>>>> I
>>>>> think.
>>>>>
>>>>> I am not sure if I am doing something wrong, the code I use is based in
>>>>> the
>>>>> simple-webservice pattern, no new things where added
>>>>>
>>>>> I will greatly appreciate an answer :)
>>>>>
>>>>> 05/08/2008 04:53:28 PM
>>>>> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
>>>>> buildServiceFromWSDL
>>>>> INFO: Creating Service {http://10.129.6.137/wsdl}GemConnectWSService<
>>>>> http://10.129.6.137/wsdl%7DGemConnectWSService>from
>>>>> WSDL: http://10.129.6.137:4204/GemConnectWSImpl?wsdl
>>>>> 05/08/2008
>>>>> <http://10.129.6.137:4204/GemConnectWSImpl?wsdl05/08/2008>04:53:29
>>>>> PM org.apache.cxf.phase.PhaseInterceptorChain
>>>>>
>>>>> doIntercept
>>>>> INFO: Interceptor has thrown exception, unwinding now
>>>>> org.apache.cxf.interceptor.Fault: Could not create
>>>>> XMLStreamReader(encoding
>>>>> UTF-8).
>>>>> at
>>>>>
>>>>>
>>>>>
>>>>> org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:67)
>>>>> at
>>>>>
>>>>>
>>>>>
>>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208)
>>>>> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:429)
>>>>> at
>>>>>
>>>>>
>>>>>
>>>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1955)
>>>>> at
>>>>>
>>>>>
>>>>>
>>>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1791)
>>>>> at
>>>>> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
>>>>> at
>>>>> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:575)
>>>>> at
>>>>>
>>>>>
>>>>>
>>>>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>>>>> at
>>>>>
>>>>>
>>>>>
>>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208)
>>>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276)
>>>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222)
>>>>> at
>>>>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>>>>> at
>>>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
>>>>> at $Proxy16.listAvailableServices(Unknown Source)
>>>>> at
>>>>>
>>>>> py.com.personal.webvas.gcsmclient.ws.test.MainTest.main(MainTest.java:25)
>>>>> Caused by: com.ctc.wstx.exc.WstxIOException: Connection reset
>>>>> at
>>>>>
>>>>> com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:548)
>>>>> at
>>>>> com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:604)
>>>>> at
>>>>> com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:629)
>>>>> at
>>>>>
>>>>>
>>>>>
>>>>> com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:324)
>>>>> at
>>>>>
>>>>>
>>>>>
>>>>> org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:65)
>>>>> ... 14 more
>>>>> Caused by: java.net.SocketException: Connection reset
>>>>> at java.net.SocketInputStream.read(Unknown Source)
>>>>> at java.io.BufferedInputStream.fill(Unknown Source)
>>>>> at java.io.BufferedInputStream.read1(Unknown Source)
>>>>> at java.io.BufferedInputStream.read(Unknown Source)
>>>>> at sun.net.www.MeteredStream.read(Unknown Source)
>>>>> at java.io.FilterInputStream.read(Unknown Source)
>>>>> at
>>>>>
>>>>> sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(Unknown
>>>>> Source)
>>>>> at
>>>>>
>>>>> sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(Unknown
>>>>> Source)
>>>>> at com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:362)
>>>>> at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:110)
>>>>> at
>>>>>
>>>>>
>>>>> com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:245)
>>>>> at
>>>>>
>>>>>
>>>>>
>>>>> com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:132)
>>>>> at
>>>>>
>>>>> com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:543)
>>>>> ... 18 more
>>>>> Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: Could
>>>>> not
>>>>> create XMLStreamReader(encoding UTF-8).
>>>>> at
>>>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:175)
>>>>> at $Proxy16.listAvailableServices(Unknown Source)
>>>>> at
>>>>>
>>>>> py.com.personal.webvas.gcsmclient.ws.test.MainTest.main(MainTest.java:25)
>>>>> Caused by: org.apache.cxf.interceptor.Fault: Could not create
>>>>> XMLStreamReader(encoding UTF-8).
>>>>> at
>>>>>
>>>>>
>>>>>
>>>>> org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:67)
>>>>> at
>>>>>
>>>>>
>>>>>
>>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208)
>>>>> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:429)
>>>>> at
>>>>>
>>>>>
>>>>>
>>>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1955)
>>>>> at
>>>>>
>>>>>
>>>>>
>>>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1791)
>>>>> at
>>>>> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
>>>>> at
>>>>> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:575)
>>>>> at
>>>>>
>>>>>
>>>>>
>>>>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>>>>> at
>>>>>
>>>>>
>>>>>
>>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208)
>>>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276)
>>>>> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222)
>>>>> at
>>>>> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>>>>> at
>>>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
>>>>> ... 2 more
>>>>> Caused by: com.ctc.wstx.exc.WstxIOException: Connection reset
>>>>> at
>>>>>
>>>>> com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:548)
>>>>> at
>>>>> com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:604)
>>>>> at
>>>>> com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:629)
>>>>> at
>>>>>
>>>>>
>>>>>
>>>>> com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:324)
>>>>> at
>>>>>
>>>>>
>>>>>
>>>>> org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:65)
>>>>> ... 14 more
>>>>> Caused by: java.net.SocketException: Connection reset
>>>>> at java.net.SocketInputStream.read(Unknown Source)
>>>>> at java.io.BufferedInputStream.fill(Unknown Source)
>>>>> at java.io.BufferedInputStream.read1(Unknown Source)
>>>>> at java.io.BufferedInputStream.read(Unknown Source)
>>>>> at sun.net.www.MeteredStream.read(Unknown Source)
>>>>> at java.io.FilterInputStream.read(Unknown Source)
>>>>> at
>>>>>
>>>>> sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(Unknown
>>>>> Source)
>>>>> at
>>>>>
>>>>> sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(Unknown
>>>>> Source)
>>>>> at com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:362)
>>>>> at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:110)
>>>>> at
>>>>>
>>>>>
>>>>> com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:245)
>>>>> at
>>>>>
>>>>>
>>>>>
>>>>> com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:132)
>>>>> at
>>>>>
>>>>> com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:543)
>>>>> ... 18 more
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>>
>>>>>
>>>>> http://www.nabble.com/WebServices-too-long-result-tp18840342p18840342.html
>>>>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Karan Singh Malhi
>>>>
>>>
>>>
>>
>>
>> --
>> Karan Singh Malhi
>
>
--
Thanks
- Mohammad Nour
