Sergey,
It is working now for me. thanks. 
I just followed the email chain keenly and found out few things to get this
working.

Thanks
Rajesh Badam


Sergey Beryozkin-5 wrote:
> 
> Can you be more specific please ? How do use it, what does not work ?
> 
> cheers, Sergey
> 
> On Tue, Jun 15, 2010 at 2:48 PM, rkbadam <[email protected]> wrote:
> 
>>
>> I am implementing similar functionality, I am forwarding to login.jsp
>> using
>> requestDispatcher, but seems to be it does't work.
>> if you have peace of code with all the steps related to this helps me
>> lot.
>> Thanks
>> Rajesh Badam
>>
>>
>> Paul Wilton wrote:
>> >
>> > No worries - thanks for helping me out.
>> >
>> >
>> >
>> >
>> >
>> > From: Sergey Beryozkin [mailto:[email protected]]
>> > Sent: 06 January 2010 12:31
>> > To: [email protected]; Paul Wilton; [email protected]
>> > Subject: RE: another question on RequestDispatcherProvider
>> >
>> >
>> >
>> >
>> >
>> > Hi,
>> >
>> > I've verified that the 2nd option (using CXFServlet) is basically
>> > identical to the first one, I had to do :
>> >
>> > <init-param>
>> >     <param-name>redirect-list</param-name>
>> >     <param-value>/WEB-INF/book.jsp</param-value>
>> > </init-param>
>> >
>> > <init-param>
>> >     <param-name>redirect-servlet-name</param-name>
>> >     <param-value>jsp</param-value>
>> > </init-param>
>> >
>> > Without the redirect-servlet-name parameter CXFServlet with a "/"
>> > pattern will be reentered after this CXFServlet has tried to forward.
>> >
>> > So, to summarize, if we have CXFServlet with a "/" pattern then the
>> > following options are available as far as redirection to jsp or indeed
>> > some other resources/servlets is concerned :
>> >
>> > 1. RequestDispacterProvider configuration in Spring has to include a
>> > dispatcherName property to avoid a CXFServlet reentrance.
>> > 2. Alternatively, CXFServlet has to include the 2 init parameters,
>> > similar to the above one, but for private resources the option 1 would
>> > likely be preferred and indeed option 1 will be just slightly more
>> > effective
>> > It might make sense to combine the 2 options if users are allowed to
>> > directly interact with some resources, ex, when redirecting to diff
>> URIs
>> > or when both external users and RequestDispatcherProvider reuse the
>> same
>> > resources such as JSP pages, etc
>> >
>> > thanks Paul for experimenting with this feature
>> > cheers, Sergey
>> >
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: Sergey Beryozkin [mailto:[email protected]]
>> > Sent: Wed 1/6/2010 5:03 AM
>> > To: Paul Wilton; [email protected]
>> > Subject: RE: another question on RequestDispatcherProvider
>> >
>> >
>> > Hi Paul
>> >
>> > thanks for the confirmation, I'll update the docs. But will also play a
>> > bit with the 2nd option to make sure it also works given that both
>> > RequestDispatchProvider and CXFServlet will create a custom
>> > HttpServletRequest wrapper, so I'd like to test that no interference
>> > will occur...
>> >
>> > cheers, Sergey
>> >
>> > -----Original Message-----
>> > From: Paul Wilton [mailto:[email protected]]
>> > Sent: Wed 1/6/2010 5:01 AM
>> > To: Sergey Beryozkin; [email protected]
>> > Subject: RE: another question on RequestDispatcherProvider
>> >
>> > Hi Sergey
>> >
>> > Option 1 works : )
>> >
>> >
>> >
>> > Thanks
>> >
>> > Paul
>> >
>> >
>> >
>> >
>> >
>> > From: Sergey Beryozkin [mailto:[email protected]]
>> > Sent: 05 January 2010 17:45
>> > To: Paul Wilton; [email protected]
>> > Subject: RE: another question on RequestDispatcherProvider
>> >
>> >
>> >
>> >
>> >
>> > Hi Paul
>> >
>> > I have tried to modify CXFServlet listening on '/' to block if it is a
>> > /WEB-INF/* pathImfo which is being processed now, but I've observed
>> what
>> > you did. Basically, when a RequestDispatcherProvider forwards, the
>> first
>> > servlet which gets this forward request is the same CXFServlet so
>> > blocking it just results in the original forward request being blocked
>> > and thus an empty response is returned.
>> >
>> > So here is what can be done here :
>> >
>> > 1. add
>> >
>> > <property name="dispatcherName" value="jsp"/>
>> >
>> > to
>> >
>> > <bean id="dispatchProvider1"
>> > class="org.apache.cxf.jaxrs.provider.RequestDispatcherProvider">
>> >
>> >         <property name="resourcePath" value="/WEB-INF/jsp/test.jsp"/>
>> >
>> >         <property name="scope" value="request"/>
>> >
>> >     </bean>
>> >
>> > it will restrict the space a bit and will exclude CXFServlet from a
>> list
>> > of candidates, as far as RequestDispatcher.forward(...) is concerned.
>> >
>> >
>> > I have tried it from Eclipse, though I will need to update it to ensure
>> > JDK but not JRE is used by default for JSP pages be compiled...But
>> > CXFServlet is definitely bypassed.
>> >
>> > 2. If it is feasible to make your jsp pages public by moving them one
>> > level higher from /WEB-INF, say to /jsp/..., then configuring
>> CXFServlet
>> > to redirect to /jsp/test.jsp will do the trick. What will happen is
>> that
>> > RequestDispatcherProvider will forward and CXFServlet will forward it
>> > further... I think the reason it could not forward to /WEB-INF was that
>> > private resources under /WEB-INF are not visible at the CXFServlet
>> > level...
>> >
>> > hope it helps, can you please try one of the above options ?
>> >
>> > thanks, Sergey
>> >
>> > -----Original Message-----
>> > From: Paul Wilton [mailto:[email protected]]
>> > Sent: Tue 1/5/2010 10:01 AM
>> > To: Sergey Beryozkin
>> > Cc: [email protected]
>> > Subject: RE: another question on RequestDispatcherProvider
>> >
>> > Hi Sergey
>> >
>> > I have tried extending the CXFServlet and overriding the redirect
>> method
>> > as you suggest. But the response is empty by that time -
>> >
>> > By the time redirect method is invoked has the CXFServlet already
>> > intercepted the  .jsp request and created a new Response (discarding
>> the
>> > one generated when the JSP was initially processed by the servlet
>> > container) ?
>> >
>> >
>> >
>> >
>> > This e-mail (and any attachments) is confidential and may contain
>> > personal views which are not the views of the BBC unless specifically
>> > stated. If you have received it in error, please delete it from your
>> > system. Do not use, copy or disclose the information in any way nor act
>> > in reliance on it and notify the sender immediately.
>> >
>> > Please note that the BBC monitors e-mails sent or received. Further
>> > communication will signify your consent to this
>> >
>> > This e-mail has been sent by one of the following wholly-owned
>> > subsidiaries of the BBC:
>> >
>> > BBC Worldwide Limited, Registration Number: 1420028 England, Registered
>> > Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
>> > BBC World News Limited, Registration Number: 04514407 England,
>> > Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
>> > BBC World Distribution Limited, Registration Number: 04514408,
>> > Registered Address: BBC Media Centre, 201 Wood Lane, London, W12 7TQ
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/another-question-on-RequestDispatcherProvider-tp27013444p28891547.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: 
http://old.nabble.com/another-question-on-RequestDispatcherProvider-tp27013444p28895658.html
Sent from the cxf-user mailing list archive at Nabble.com.

Reply via email to