Re: ServletSource outside of pipeline

[Robin Wyles]

On 4 Aug 2008, at 15:02, Reinhard Pötz wrote:

Robin Wyles wrote:

On 4 Aug 2008, at 13:24, Reinhard Pötz wrote:

Reinhard Pötz wrote:

Robin Wyles wrote:

Hi,



java.lang.NullPointerException

I have a component in my app that uses SourceResolver to create a ServletSource. When I call this component from within a pipeline, e.g. from flow or from a sitemap component all works well. However, when I call this method from a cron job I get the following NPE: at org.apache.cocoon.callstack.environment.CallFrameHelper.getContext (CallFrameHelper.java:75) at org.apache.cocoon.servletservice.CallStackHelper.getCurrentServlet Context(CallStackHelper.java:112) at org.apache.cocoon.servletservice.components.ServletSource.createSe rvletConnection(ServletSource.java:125)

<snip/>

The root problem seems to be that the CallStack is empty and so the the current ServletContext cannot be obtained using CallStackHelper.getCurrentServletContext().

Am I doing anything wrong?

IMO no. From a quick glance at the code I think it needs to be more defensive in terms of catching NPEs. In the case that there is no existing call frame, null should be returned. Grzegorz, what do you think?

I've just committed a fix for this (revision 682356) so that *absolute* servlet URLs *should* work. (It can never work for self-referenced servlet URLs or relative servlet URLs without an existing servlet service request.)

Many thanks for committing this so quickly Reinhard... Ok, so testing with an absolute servlet URL (servlet:james-publisher+:/my/ matcher) I now get:

java.lang.IllegalArgumentException: ServletContext must not be null
    at org.springframework.util.Assert.notNull(Assert.java:112)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

Any ideas?

at org.springframework.web.context.support.WebApplicationContextUtils.ge tWebApplicationContext(WebApplicationContextUtils.java:63) at org.springframework.web.context.support.WebApplicationContextUtils.ge tRequiredWebApplicationContext(WebApplicationContextUtils.java: 93) at org.apache.cocoon.servletservice.AbsoluteServletConnection.<init> (AbsoluteServletConnection.java:56) at org.apache.cocoon.servletservice.components.ServletSource.createServl etConnection(ServletSource.java:151) at org.apache.cocoon.servletservice.components.ServletSource.<init> (ServletSource.java:73) at org.apache.cocoon.servletservice.components.ServletSourceFactory.getS ource(ServletSourceFactory.java:74) at org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI (CocoonSourceResolver.java:153) at org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI (CocoonSourceResolver.java:183) at com.jac.james.publisher.Publisher.publishFeed(Publisher.java:301) at com.jac.james.publisher.Publisher.schedulePublishFeed (Publisher.java:385) at com.jac.james.publisher.Publisher.refreshPublishJobs (Publisher.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.springframework.util.MethodInvoker.invoke (MethodInvoker.java:276) at org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryB ean$MethodInvokingJob.executeInternal (MethodInvokingJobDetailFactoryBean.java:260) at org.springframework.scheduling.quartz.QuartzJobBean.execute (QuartzJobBean.java:86) at org.quartz.core.JobRunShell.run (JobRunShell.java:202) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run (SimpleThreadPool.java:529) Seems here that AbsoluteServletConnection tries to obtain the servlet context from CallStackHelper, which again of course relies on there being a call stack....

I think that I was too optimistic that this can be easily fixed :-(

It seems like a can of worms... I appreciate you checking it out though.

And there might be more ...

Currently I have no idea how I can get access to the Spring application context without having a current context. Additionally there are more problems waiting: When a new ServletService request is created, it gets the calling request set as parent. In this case this would be null and should be replaced by a special parent request that works in non-http environments.

Thanks again,

Robin

Yikes... looks like it's back to httpclient to achieve my goals in this area for the time being :( Seems a shame though when in this case all I'm doing is posting the results of one pipeline to another within my app...

smime.p7s
Description: S/MIME cryptographic signature