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 [EMAIL PROTECTED]
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
