You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Robin Wyles <ro...@robinwyles.com> on 2008/08/04 13:14:01 UTC
ServletSource outside of pipeline
Hi,
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:
java.lang.NullPointerException
at org.apache.cocoon.callstack.environment.CallFrameHelper.getContext
(CallFrameHelper.java:75)
at
org.apache.cocoon.servletservice.CallStackHelper.getCurrentServletContex
t(CallStackHelper.java:112)
at
org.apache.cocoon.servletservice.components.ServletSource.createServletC
onnection(ServletSource.java:125)
at org.apache.cocoon.servletservice.components.ServletSource.<init>
(ServletSource.java:72)
at
org.apache.cocoon.servletservice.components.ServletSourceFactory.getSour
ce(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 org.apache.cocoon.rest.util.DOMPoster.postToPipeline
(DOMPoster.java:57)
at com.jac.james.publisher.Publisher.uploadEntryFiles(Publisher.java:
224)
at com.jac.james.publisher.Publisher.doUploads(Publisher.java:198)
at sun.reflect.GeneratedMethodAccessor148.invoke(Unknown Source)
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.MethodInvokingJobDetailFactoryBean
$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)
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?
Thanks,
Robin
Re: ServletSource outside of pipeline
Posted by Reinhard Pötz <re...@apache.org>.
Robin Wyles wrote:
>
> 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,
>>>>>>
>>>>>> 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:
>>>>>>
>>>>>> java.lang.NullPointerException
>>>>>> at
>>>>>> org.apache.cocoon.callstack.environment.CallFrameHelper.getContext(CallFrameHelper.java:75)
>>>>>>
>>>>>> at
>>>>>> org.apache.cocoon.servletservice.CallStackHelper.getCurrentServletContext(CallStackHelper.java:112)
>>>>>>
>>>>>> at
>>>>>> org.apache.cocoon.servletservice.components.ServletSource.createServletConnection(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
>>> org.springframework.web.context.support.WebApplicationContextUtils.getWebApplicationContext(WebApplicationContextUtils.java:63)
>>> at
>>> org.springframework.web.context.support.WebApplicationContextUtils.getRequiredWebApplicationContext(WebApplicationContextUtils.java:93)
>>> at
>>> org.apache.cocoon.servletservice.AbsoluteServletConnection.<init>(AbsoluteServletConnection.java:56)
>>> at
>>> org.apache.cocoon.servletservice.components.ServletSource.createServletConnection(ServletSource.java:151)
>>> at
>>> org.apache.cocoon.servletservice.components.ServletSource.<init>(ServletSource.java:73)
>>> at
>>> org.apache.cocoon.servletservice.components.ServletSourceFactory.getSource(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.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:585)
>>> at
>>> org.springframework.util.MethodInvoker.invoke(MethodInvoker.java:276)
>>> at
>>> org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean$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....
>>> Any ideas?
>>
>> 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.
>>
>> 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.
>>
>> And there might be more ...
>
> 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...
yes, that far from being optimal.
Could you file a bug report that points to this discussion so that this
issue doesn't get forgotten?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ServletSource outside of pipeline
Posted by Reinhard Pötz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Robin Wyles pisze:
>>
>> Yikes... looks like it's back to httpclient to achieve my goals in
>> this area for the time being :(
>
> Is it possible that you create artificial Servlet for your background job?
>
> Then you could call this servlet (which is a Spring bean) and inside
> service() method of your servlet you can be sure that you have a right
> context properly set up so SSF will work correctly.
>
> You probably could call it with null values for both request and response.
I doubt that this will work because the parent request is passed to the
current servlet-service request. Passing null for the request will lead
to NPEs IMO.
But this shouldn't be too difficult to fix or could already work if a
valid request object is being passed.
> I'm wondering if this couldn't be transformed into general solution if
> one needs to call pipeline from outside of any context (outside of any
> servlet).
yes, maybe we can provide some wrapper for that purpose.
>> Seems a shame though when in this case all I'm doing is posting the
>> results of one pipeline to another within my app...
>
> The whole idea behind SSF is that it manages /servlets/ and cares about
> only them. The idea of connection is that, you connect two /servlets/ so
> one can pull data from another one.
>
> Your use-case, even if valid, breaks contracts of SSF because you are
> trying to connect to servlet from nowhere (at least from SSF's point of
> view). If you establish artificial servlet, and you call its service()
> method then SSF will handle this the same way as it would be request
> coming from browser. This will force it to properly initialize the
> CallStack and the whole infrastructure.
>
> Does it makes sense to you?
>
> Reinhard, what's your opinion?
I also think that it is a valid use case and would be happy to see a
general solution in the ssf-impl code.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ServletSource outside of pipeline
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Robin Wyles pisze:
>
> Yikes... looks like it's back to httpclient to achieve my goals in this
> area for the time being :(
Is it possible that you create artificial Servlet for your background job?
Then you could call this servlet (which is a Spring bean) and inside service() method of your
servlet you can be sure that you have a right context properly set up so SSF will work correctly.
You probably could call it with null values for both request and response.
I'm wondering if this couldn't be transformed into general solution if one needs to call pipeline
from outside of any context (outside of any servlet).
> Seems a shame though when in this case all I'm doing is posting the
> results of one pipeline to another within my app...
The whole idea behind SSF is that it manages /servlets/ and cares about only them. The idea of
connection is that, you connect two /servlets/ so one can pull data from another one.
Your use-case, even if valid, breaks contracts of SSF because you are trying to connect to servlet
from nowhere (at least from SSF's point of view). If you establish artificial servlet, and you call
its service() method then SSF will handle this the same way as it would be request coming from
browser. This will force it to properly initialize the CallStack and the whole infrastructure.
Does it makes sense to you?
Reinhard, what's your opinion?
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ServletSource outside of pipeline
Posted by Robin Wyles <ro...@robinwyles.com>.
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,
>>>>>
>>>>> 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:
>>>>>
>>>>> java.lang.NullPointerException
>>>>> 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
>> 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.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: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....
>> Any ideas?
>
> 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.
>
> 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.
>
> And there might be more ...
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...
Thanks again,
Robin
Re: ServletSource outside of pipeline
Posted by Reinhard Pötz <re...@apache.org>.
Robin Wyles wrote:
>
> On 4 Aug 2008, at 13:24, Reinhard Pötz wrote:
>
>> Reinhard Pötz wrote:
>>> Robin Wyles wrote:
>>>> Hi,
>>>>
>>>> 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:
>>>>
>>>> java.lang.NullPointerException
>>>> at
>>>> org.apache.cocoon.callstack.environment.CallFrameHelper.getContext(CallFrameHelper.java:75)
>>>>
>>>> at
>>>> org.apache.cocoon.servletservice.CallStackHelper.getCurrentServletContext(CallStackHelper.java:112)
>>>>
>>>> at
>>>> org.apache.cocoon.servletservice.components.ServletSource.createServletConnection(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
> org.springframework.web.context.support.WebApplicationContextUtils.getWebApplicationContext(WebApplicationContextUtils.java:63)
>
> at
> org.springframework.web.context.support.WebApplicationContextUtils.getRequiredWebApplicationContext(WebApplicationContextUtils.java:93)
>
> at
> org.apache.cocoon.servletservice.AbsoluteServletConnection.<init>(AbsoluteServletConnection.java:56)
>
> at
> org.apache.cocoon.servletservice.components.ServletSource.createServletConnection(ServletSource.java:151)
>
> at
> org.apache.cocoon.servletservice.components.ServletSource.<init>(ServletSource.java:73)
>
> at
> org.apache.cocoon.servletservice.components.ServletSourceFactory.getSource(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.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:585)
> at
> org.springframework.util.MethodInvoker.invoke(MethodInvoker.java:276)
> at
> org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean$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....
>
> Any ideas?
I think that I was too optimistic that this can be easily fixed :-(
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.
And there might be more ...
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ServletSource outside of pipeline
Posted by Robin Wyles <ro...@robinwyles.com>.
On 4 Aug 2008, at 13:24, Reinhard Pötz wrote:
> Reinhard Pötz wrote:
>> Robin Wyles wrote:
>>> Hi,
>>>
>>> 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:
>>>
>>> java.lang.NullPointerException
>>> at
>>> org.apache.cocoon.callstack.environment.CallFrameHelper.getContext
>>> (CallFrameHelper.java:75)
>>> at
>>> org.apache.cocoon.servletservice.CallStackHelper.getCurrentServletCo
>>> ntext(CallStackHelper.java:112)
>>> at
>>> org.apache.cocoon.servletservice.components.ServletSource.createServ
>>> letConnection(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
org.springframework.web.context.support.WebApplicationContextUtils.getWe
bApplicationContext(WebApplicationContextUtils.java:63)
at
org.springframework.web.context.support.WebApplicationContextUtils.getRe
quiredWebApplicationContext(WebApplicationContextUtils.java:93)
at org.apache.cocoon.servletservice.AbsoluteServletConnection.<init>
(AbsoluteServletConnection.java:56)
at
org.apache.cocoon.servletservice.components.ServletSource.createServletC
onnection(ServletSource.java:151)
at org.apache.cocoon.servletservice.components.ServletSource.<init>
(ServletSource.java:73)
at
org.apache.cocoon.servletservice.components.ServletSourceFactory.getSour
ce(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.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:585)
at org.springframework.util.MethodInvoker.invoke(MethodInvoker.java:
276)
at
org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean
$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....
Any ideas?
>
> Unfortunately I don't have a test case and currently no idea how I
> can provide a simple environment. This means that I'm not sure if
> there are other locations that have a problem if there is no
> existing servlet service requuest.
>
> Any ideas for a test environment?
Unfortunately not - I'm not sure how I can set up a SSF managed
servlet inside a test...
Cheers,
Robin
Re: ServletSource outside of pipeline
Posted by Reinhard Pötz <re...@apache.org>.
Reinhard Pötz wrote:
> Robin Wyles wrote:
>> Hi,
>>
>> 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:
>>
>> java.lang.NullPointerException
>> at
>> org.apache.cocoon.callstack.environment.CallFrameHelper.getContext(CallFrameHelper.java:75)
>>
>> at
>> org.apache.cocoon.servletservice.CallStackHelper.getCurrentServletContext(CallStackHelper.java:112)
>>
>> at
>> org.apache.cocoon.servletservice.components.ServletSource.createServletConnection(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.)
Unfortunately I don't have a test case and currently no idea how I can
provide a simple environment. This means that I'm not sure if there are
other locations that have a problem if there is no existing servlet
service requuest.
Any ideas for a test environment?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ServletSource outside of pipeline
Posted by Reinhard Pötz <re...@apache.org>.
Robin Wyles wrote:
> Hi,
>
> 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:
>
> java.lang.NullPointerException
> at
> org.apache.cocoon.callstack.environment.CallFrameHelper.getContext(CallFrameHelper.java:75)
>
> at
> org.apache.cocoon.servletservice.CallStackHelper.getCurrentServletContext(CallStackHelper.java:112)
>
> at
> org.apache.cocoon.servletservice.components.ServletSource.createServletConnection(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?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org