HttpServletRequest in webservice

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

HttpServletRequest in webservice

typhoon
This post was updated on .
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: HttpServletRequest in webservice

typhoon
This post was updated on .
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: HttpServletRequest in webservice

typhoon
This post was updated on .
In reply to this post by typhoon
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: HttpServletRequest in webservice

dblevins
Administrator

On Oct 21, 2010, at 12:08 PM, typhoon wrote:

>
> Guys, please respond...

As an FYI, we've been having issues with Nabble.  Looks like this is one of the many messages Nabble never delivered:

  http://mail-archives.apache.org/mod_mbox/openejb-users/201010.mbox/browser


Quoting the original message:
> I'm trying to create a unit test for web service that stores some objects in HttpSession (via setAttribute).
> When this test is executed (using approach similar to the 'simple-webservice' test testCalculatorViaWsInterface), then WebServiceContext.getMessageContext().get(MessageContext.SERVLET_REQUEST) returns null.
> I checked MessageContext and it has key MessageContext.SERVLET_REQUEST with null value.
> Is it supported in OpenEJB?

I dug into this and it looks like those entries will be populated correctly if Jetty is added to the test classpath.  We have a lightweight HTTP implementation that attempts to minimally mock some of the Servlet API, but it is pretty minimalistic.  If Jetty jars in the classpath we will always prefer their HTTP code to our own.

Looks like with Jetty the following entries are in the HttpRequest.getAttributes bucket and are successfully copied into the MessageContext:
 - SERVLET_REQUEST
 - SERVLET_RESPONSE
 - SERVLET_CONTEXT

Just need to add this dependency:

    <dependency>
      <groupId>org.mortbay.jetty</groupId>
      <artifactId>jetty-embedded</artifactId>
      <version>6.1.7</version>
      <exclusions>
        <exclusion>
          <groupId>org.mortbay.jetty</groupId>
          <artifactId>servlet-api-2.5</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

We can probably make this work with our minimal HTTP implementation as well.  On the examples front, if you wanted to send a little patch in for the 'simple-webservice', we could show it functioning there as well.

In terms for future dev, Jonathan Gallimore has done some interesting things in trunk with Jetty/OpenEJB integration that *is* embeddable in a unit test.  Don't think it supports scanning for @WebService components yet, but definitely that would be a welcome addition.  If you're interested in hacking or seeing what's there, hop on [hidden email].  We are a user-run project, the more the merrier!


-David

Reply | Threaded
Open this post in threaded view
|

Re: HttpServletRequest in webservice

typhoon
This post was updated on .
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: HttpServletRequest in webservice

typhoon
This post was updated on .
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: HttpServletRequest in webservice

dblevins
Administrator
In reply to this post by typhoon

On Oct 22, 2010, at 2:57 AM, typhoon wrote:

>
> Thanks David!
> I added dependency (v 6.1.23), but now get the following exception:
>
> Caused by: org.apache.cxf.binding.soap.SoapFault: The bean encountered a
> non-application exception; nested exception is:
> java.lang.IllegalStateException: No SessionHandler or SessionManager while
> invoking public abstract ... with params [...].
> at
> org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:75)

Thanks for the revised CalculatorImpl.  I added that to a setup that has all the expected Jetty libraries and got the same outcome.  Specifically, this is the 'Caused by' part of that stacktrace:

Caused by: java.lang.IllegalStateException: No SessionHandler or SessionManager
        at org.mortbay.jetty.Request.getSession(Request.java:1022)
        at org.mortbay.jetty.Request.getSession(Request.java:1012)
        at org.superbiz.calculator.CalculatorImpl.sum(CalculatorImpl.java:59)
        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.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:162)
        at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:144)
        at org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:164)
        at org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:92)
        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.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:162)
        at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:144)
        at org.apache.openejb.server.cxf.ejb.EjbMethodInvoker.performInvocation(EjbMethodInvoker.java:85)
        at org.apache.openejb.server.cxf.ejb.EjbMethodInvoker.directEjbInvoke(EjbMethodInvoker.java:173)
        at org.apache.openejb.server.cxf.ejb.EjbInterceptor.intercept(EjbInterceptor.java:97)
        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.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:162)
        at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:144)
        at org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:128)
        at org.apache.openejb.core.stateless.StatelessContainer.invokeWebService(StatelessContainer.java:302)
        at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:217)
        ... 28 more

Seems if we wanted to more fully enable Jetty in this regard there might be some additional setup required beyond what we do now.

Jonathan has done the most Jetty tinkering as of late and might have an idea on what the missing sauce is.  Jon, run into anything like this before in your trunk Jetty work?


-David

Reply | Threaded
Open this post in threaded view
|

Re: HttpServletRequest in webservice

jgallimore
I haven't wired up anything in terms of webservices just yet, so I'm afraid
I don't know what's missing at the moment. In terms of the Jetty stuff I'm
at the point where I think most of the JNDI bits between Jetty and OpenEJB
are wired up correctly, and I'd like to get the itests passing soon.

I'll have a poke around with this and see if I can help.

Jon

On Wed, Oct 27, 2010 at 12:33 AM, David Blevins <[hidden email]>wrote:

>
> On Oct 22, 2010, at 2:57 AM, typhoon wrote:
>
> >
> > Thanks David!
> > I added dependency (v 6.1.23), but now get the following exception:
> >
> > Caused by: org.apache.cxf.binding.soap.SoapFault: The bean encountered a
> > non-application exception; nested exception is:
> >       java.lang.IllegalStateException: No SessionHandler or
> SessionManager while
> > invoking public abstract ... with params [...].
> >       at
> >
> org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:75)
>
> Thanks for the revised CalculatorImpl.  I added that to a setup that has
> all the expected Jetty libraries and got the same outcome.  Specifically,
> this is the 'Caused by' part of that stacktrace:
>
> Caused by: java.lang.IllegalStateException: No SessionHandler or
> SessionManager
>        at org.mortbay.jetty.Request.getSession(Request.java:1022)
>        at org.mortbay.jetty.Request.getSession(Request.java:1012)
>        at
> org.superbiz.calculator.CalculatorImpl.sum(CalculatorImpl.java:59)
>        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.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:162)
>        at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:144)
>        at
> org.apache.openejb.monitoring.StatsInterceptor.record(StatsInterceptor.java:164)
>        at
> org.apache.openejb.monitoring.StatsInterceptor.invoke(StatsInterceptor.java:92)
>        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.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:162)
>        at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:144)
>        at
> org.apache.openejb.server.cxf.ejb.EjbMethodInvoker.performInvocation(EjbMethodInvoker.java:85)
>        at
> org.apache.openejb.server.cxf.ejb.EjbMethodInvoker.directEjbInvoke(EjbMethodInvoker.java:173)
>        at
> org.apache.openejb.server.cxf.ejb.EjbInterceptor.intercept(EjbInterceptor.java:97)
>        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.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:162)
>        at
> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:144)
>        at
> org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:128)
>        at
> org.apache.openejb.core.stateless.StatelessContainer.invokeWebService(StatelessContainer.java:302)
>        at
> org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:217)
>        ... 28 more
>
> Seems if we wanted to more fully enable Jetty in this regard there might be
> some additional setup required beyond what we do now.
>
> Jonathan has done the most Jetty tinkering as of late and might have an
> idea on what the missing sauce is.  Jon, run into anything like this before
> in your trunk Jetty work?
>
>
> -David
>
>
Reply | Threaded
Open this post in threaded view
|

Re: HttpServletRequest in webservice

typhoon
This post was updated on .
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: HttpServletRequest in webservice

dblevins
Administrator
On Wed, Nov 10, 2010 at 4:49 AM, typhoon <[hidden email]> wrote:

>
> I created a patch for this issue based on code in 3.1.3.
> Update details:
>
> <<         context.setHandler(handler);
>
>>>         SessionHandler sessionHandler = new SessionHandler();
>>>         SessionManager sessionManager = new HashSessionManager();
>>>         sessionManager.setIdManager(new HashSessionIdManager());
>>>         sessionHandler.setSessionManager(sessionManager);
>>>         sessionHandler.setHandler(handler);
>>>
>>>         context.setHandler(sessionHandler);
>
> Session is returned with this small update.
>
> Attaching full file.
> http://openejb.979440.n4.nabble.com/file/n3036011/JettyHttpServer.java
> JettyHttpServer.java
>
> It would be great if this one could be included into 3.1.4 release.
>

Got that committed and filed a JIRA for it and it will be in 3.1.4.

  https://issues.apache.org/jira/browse/OPENEJB-1395

If you have a JIRA id, let me know.  I'd like to add you to the
openejb-contributor permissions group mark the issue as completed by
you.  Congrats on your first patch!

Thanks so much!

-David