Re: Firefox 3 and URL
Okay,
My problem is now fixed.
Instead of using HEAD request, i have used GET request :
this.xmlHttp.open("GET", resourceName, false);
this.xmlHttp.send(null);
I think that Firefox 2.0 and Firefox 3.0 have different behaviour of how to
handle request.
For FF3
*In the case of this.xmlHttp.open("HEAD", resourceName, false); : i have no
responseXML (null)
*In the case of this.xmlHttp.open("GET", resourceName, false); : i have
responseXML
For FF2
*In the case of this.xmlHttp.open("HEAD", resourceName, false); : i have
responseXML
*In the case of this.xmlHttp.open("GET", resourceName, false); : i have
responseXML
Why this different behavior?
Thanks,
Alexandre
Alexandre Mazouz wrote:
>
> Hello,
>
> After a lot of debugging and other things, i have found a new problem with
> FF3.
> In FF2, IE6, IE7 it works fine but not in FF3.
>
> ***
> if (!this.xmlHttp) {
> this.xmlHttp = Sarissa.getXmlHttpRequest();
> }
> this.xmlHttp.open("HEAD", resourceName, false);
> this.xmlHttp.send(null);
> return (this.xmlHttp.status == 200 && this.xmlHttp.responseXML);
> ***
> the resourceName is "/dy/browse/bv/nr500/nr500_2008/loc/n0001.xml".
> the statusText is "OK" and status 200.
>
> i have no responseXML.
>
> something seems strange is that when the this.xmlHttp.open is done, i have
> the this.xmlHttp.statusText=this.xmlHttp.channel
>
> all seems to be fine but i get nothing in FF3 (responseXML=null).
>
> Is there any idea from where is the problem and how to fix it?
>
> Thanks,
> Alexandre
>
>
--
View this message in context:
http://www.nabble.com/Firefox-3-and-URL-tp18212745p18809075.html
Sent from the Cocoon - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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. (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 smime.p7s Description: S/MIME cryptographic signature
Re: Cocoon 2.2 flowscipt debugger possible?
Hi, I just noticed this change this morning when I updated to latest trunk... lo and behold the flowscript debugger started up when I ran my app which seemed to cause all sorts of issues when testing in Eclipse, and using mvn jetty:run... So my question should the FlowScript debugger really be enabled by default for dev mode? Robin On 1 Aug 2008, at 15:29, Grzegorz Kossakowski wrote: Hugh Sparks pisze: I read a few posts that suggest that this is impossible, but I decided to try the flowscript debugger anyway. I'm running under Tomcat, so I copied the file cocoon-flowscipt.xconf from the cocoon 2.2 svn truck to this directory in my Tomcat installation: webapps\cocoon\WEB-INF\classes\META-INF\cocoon\avalon I edited the file to enable the debugger and started Tomcat. When I ran my cocoon flowscript application, the debugger window appeared, but the application crashes. Here are some highlights from the traceback: description The server encountered an internal error () that prevented it from fulfilling this request. org.apache.avalon.framework.service.ServiceException: Exception during lookup of component with 'org.apache.cocoon.components.flow.Interpreter/javascript'. (Key='AvalonServiceManager') org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cocoon.components.flow.Interpreter/javascript': Initialization of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Unable to initialize Avalon component with role org.apache.cocoon.components.flow.Interpreter/javascript; nested exception is java.lang.IllegalStateException If I remove the cocoon-flowscript.xconf file, the application works normally. I realized that Avalon is on the way out, but should this work? What is the current best practice to use the debugger in its present form? Thanks to all, Hi Hugh, This has been fixed in trunk, see: http://article.gmane.org/gmane.text.xml.cocoon.cvs/27138 If you want to use this fixed version, you will need to checkout trunk and build it. Then just add SNAPSHOT dependency to your pom (of your project). There is no need to switch with all Cocoon dependencies to SNAPSHOT versions. Also, you might be interested in following commit: http://article.gmane.org/gmane.text.xml.cocoon.cvs/27140 -- Best regards, Grzegorz Kossakowski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: Cocoon 2.2 flowscipt debugger possible?
Robin Wyles pisze: Hi, Hi Robin, I just noticed this change this morning when I updated to latest trunk... lo and behold the flowscript debugger started up when I ran my app which seemed to cause all sorts of issues when testing in Eclipse, and using mvn jetty:run... So my question should the FlowScript debugger really be enabled by default for dev mode? Could you elaborate on these issues you face? If there are some serious problems then I think we'll switch it off again. Actually, you can do it yourself very easily but still defaults are important. -- Grzegorz Kossakowski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Firefox 3 and URL
2008/8/4 Alexandre Mazouz <[EMAIL PROTECTED]>:
>
> Okay,
>
> My problem is now fixed.
>
> Instead of using HEAD request, i have used GET request :
>
> this.xmlHttp.open("GET", resourceName, false);
> this.xmlHttp.send(null);
>
> I think that Firefox 2.0 and Firefox 3.0 have different behaviour of how to
> handle request.
>
> For FF3
> *In the case of this.xmlHttp.open("HEAD", resourceName, false); : i have no
> responseXML (null)
> *In the case of this.xmlHttp.open("GET", resourceName, false); : i have
> responseXML
>
> For FF2
> *In the case of this.xmlHttp.open("HEAD", resourceName, false); : i have
> responseXML
> *In the case of this.xmlHttp.open("GET", resourceName, false); : i have
> responseXML
>
> Why this different behavior?
Given the point of a HEAD request is to fetch the response headers
without the actual body [1], I'm surprised you expected responseXML to
contain anything in the first place. Are you sure the XHR
open("HEAD", ...) in FF2 is actually sending a HEAD and not using a
GET anyway? It could be that version doesn't support HEAD and falls
back on the other method, and they've improved things by v3. I'd be
tempted to try a packet sniffer or the Live HTTP Headers extension to
see exactly what gets sent & received. Also check the web server
access logs to see what method it thinks was used in each case. I'd
be surprised if the server responded differently to HEAD requests
according to the browser version, returning the content body in one
case and not the other. What server software are you using anyway?
Andy.
[1] http://en.wikipedia.org/wiki/HTTP_HEAD_request#Request_methods
--
http://pseudoq.sourceforge.net/ Open source java Sudoku application
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletSource outside of pipeline
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)
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 [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2 flowscipt debugger possible?
Hi Grzegorz, I get many errors like this: Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: No such child: 1 at java.awt.Container.getComponent(Container.java:280) at org.mozilla.javascript.tools.debugger.FileWindow.updateToolTip (SwingGui.java:2181) at org.mozilla.javascript.tools.debugger.FileWindow. (SwingGui.java:2161) at org.mozilla.javascript.tools.debugger.SwingGui.createFileWindow (SwingGui.java:486) at org.mozilla.javascript.tools.debugger.SwingGui.showFileWindow (SwingGui.java:455) at org.mozilla.javascript.tools.debugger.SwingGui.showStopLine (SwingGui.java:435) at org.mozilla.javascript.tools.debugger.SwingGui.enterInterruptImpl (SwingGui.java:583) at org.mozilla.javascript.tools.debugger.RunProxy.run(SwingGui.java: 3531) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) at java.awt.EventQueue.dispatchEvent(EventQueue.java:461) at java.awt.EventDispatchThread.pumpOneEventForHierarchy (EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForHierarchy (EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java: 184) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java: 176) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) Also, sometimes flow execution just stops as if it has reached a breakpoint - seems to be no way to continue so I have to restart the app. There also appears to be issues of cocoon.redirectTo() not working when called from flow with the debugger enabled. Please bear in minda, that these observations are all based on my five minutes of frustration this morning before I managed to disable it - they may not be wholly accurate! I do think the FlowDebugger should not be enabled by default for dev mode though - disabling requires you specifically have to add a dev properties folder to your blocks, and also have to think hard about the sometimes head-bending (but powerful!) property cascading with respect to property file names etc. Robin On 4 Aug 2008, at 12:22, Grzegorz Kossakowski wrote: Robin Wyles pisze: Hi, Hi Robin, I just noticed this change this morning when I updated to latest trunk... lo and behold the flowscript debugger started up when I ran my app which seemed to cause all sorts of issues when testing in Eclipse, and using mvn jetty:run... So my question should the FlowScript debugger really be enabled by default for dev mode? Could you elaborate on these issues you face? If there are some serious problems then I think we'll switch it off again. Actually, you can do it yourself very easily but still defaults are important. -- Grzegorz Kossakowski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: Firefox 3 and URL
I use the plugin Firebug to debug my web application.
I understand that Head request do not send response but Firebug shows me
something else in FF2.
I use Cocoon 2.1.7/Jetty/sarissa 0.9.4.4.
Thanks,
Alexandre
Andy Stevens-2 wrote:
>
> 2008/8/4 Alexandre Mazouz <[EMAIL PROTECTED]>:
>>
>> Okay,
>>
>> My problem is now fixed.
>>
>> Instead of using HEAD request, i have used GET request :
>>
>> this.xmlHttp.open("GET", resourceName, false);
>> this.xmlHttp.send(null);
>>
>> I think that Firefox 2.0 and Firefox 3.0 have different behaviour of how
>> to
>> handle request.
>>
>> For FF3
>> *In the case of this.xmlHttp.open("HEAD", resourceName, false); : i have
>> no
>> responseXML (null)
>> *In the case of this.xmlHttp.open("GET", resourceName, false); : i have
>> responseXML
>>
>> For FF2
>> *In the case of this.xmlHttp.open("HEAD", resourceName, false); : i have
>> responseXML
>> *In the case of this.xmlHttp.open("GET", resourceName, false); : i have
>> responseXML
>>
>> Why this different behavior?
>
> Given the point of a HEAD request is to fetch the response headers
> without the actual body [1], I'm surprised you expected responseXML to
> contain anything in the first place. Are you sure the XHR
> open("HEAD", ...) in FF2 is actually sending a HEAD and not using a
> GET anyway? It could be that version doesn't support HEAD and falls
> back on the other method, and they've improved things by v3. I'd be
> tempted to try a packet sniffer or the Live HTTP Headers extension to
> see exactly what gets sent & received. Also check the web server
> access logs to see what method it thinks was used in each case. I'd
> be surprised if the server responded differently to HEAD requests
> according to the browser version, returning the content body in one
> case and not the other. What server software are you using anyway?
>
>
> Andy.
> [1] http://en.wikipedia.org/wiki/HTTP_HEAD_request#Request_methods
> --
> http://pseudoq.sourceforge.net/ Open source java Sudoku application
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Firefox-3-and-URL-tp18212745p18810281.html
Sent from the Cocoon - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletSource outside of pipeline
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)
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 [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Selection list from multivaluefield
Hi All, Is it possible to set a selection list from a multivaluefield definition on the same form? The multivaluefield definition would use binding (direction=load) to move the values into the form. Currently I'm using 2.1.9. Thanks! gary <>- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrating Cocoon 2.1 project to Cocoon 2.2
On Jul 27, 2008, at 4:30 PM, Barbara Slupik wrote: In cocoon-2.2 everything runs as blocks. So you have to put your old application into one or more blocks and create cocoon-2.2 application to run them. I have to point out that it's not quite true and in reality there are other alternatives [1]. Vadim [1] http://blog.reverycodes.com/archives/45.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletSource outside of pipeline
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) 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. (AbsoluteServletConnection.java:56) at org.apache.cocoon.servletservice.components.ServletSource.createServletC onnection(ServletSource.java:151) at org.apache.cocoon.servletservice.components.ServletSource. (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 smime.p7s Description: S/MIME cryptographic signature
Re: ServletSource outside of pipeline
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)
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.(AbsoluteServletConnection.java:56)
at
org.apache.cocoon.servletservice.components.ServletSource.createServletConnection(ServletSource.java:151)
at
org.apache.cocoon.servletservice.components.ServletSource.(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 [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletSource outside of pipeline
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) 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. (AbsoluteServletConnection.java:56) at org.apache.cocoon.servletservice.components.ServletSource.createServl etConnection(ServletSource.java:151) at org.apache.cocoon.servletservice.components.ServletSource. (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 smime.p7s Description: S/MIME cryptographic signature
Re: ServletSource outside of pipeline
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)
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.(AbsoluteServletConnection.java:56)
at
org.apache.cocoon.servletservice.components.ServletSource.createServletConnection(ServletSource.java:151)
at
org.apache.cocoon.servletservice.components.ServletSource.(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 membe
File upload
Hi, When doing file upload, and the file is at such a size that the processing of the uploaded file takes quite some time, is it possible to let the user continue with the browsing while the server handles the processing in the background? IMPORTANT NOTICE: This message may contain confidential information. If you have received this e-mail in error, do not use, copy or distribute it. Do not open any attachments. Delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you.
Can anyone let me know how to start build simple cocoon project .I am using jbuilder2008
Can anyone let me know how to start build simple cocoon project .I am using jbuilder2008m .I am getting so many errors that I feel like I should start from beginning I am missing some concept. thanks
how to pass params from flowscript to the widget
Variable in the flowscript:
var composition_id = experiment.get("id_compositions");
And the widget:
Density
var value = this.value;
I need to pass "composition_id" to the widget's on-value-changed.
Re: how to pass params from flowscript to the widget
And how to execute function from the flowscript in the widget's tag?
Magsend wrote:
> Variable in the flowscript: var composition_id =
> experiment.get("id_compositions"); And the widget: required="true"> Density base="decimal"/> var value =
> this.value;I need to
> pass "composition_id" to the widget's on-value-changed.
--
View this message in context:
http://www.nabble.com/how-to-pass-params-from-flowscript-to-the-widget-tp18816044p18816714.html
Sent from the Cocoon - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Selection list from multivaluefield
You can do something like this: * definition * template * binding * object private String[] myField; Set values in myField array and they will be automatically selected on the screen. Barbara On 4 Aug, 2008, at 1:44 pm, Gary Larsen wrote: Hi All, Is it possible to set a selection list from a multivaluefield definition on the same form? The multivaluefield definition would use binding (direction=load) to move the values into the form. Currently I'm using 2.1.9. Thanks! gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding on different xml paths
Can you please explain it once again? I don't really understand your problem. Barbara On 28 Jul, 2008, at 6:00 pm, Héléna Tanguy wrote: Hello, I'm working on a cocoon form with binding on xml document. Now everything works correctly. But I must make an evolution to this form, the binding must be made on 2 xml different paths. For example: Some widgets are binded with this xml path: myData/contacts/contact [position="x"]/name, etc Some other widget must be binded with this other xml path: myData/ customers/customer[position="x"]/customerId, etc. I must display in my form the contact name and the customer id. The contact in position 1 is the same person than the customer in position 1, etc. I precise that the xml format cannot be modified, it is a standard format. In the existing form, the binding was made with "myData/contacts/ contact[position="x"]", but it is not possible to bind the other widget with this xml path. So my question is: how to do the binding with these 2 xml paths ? Is it possible to pass a parameter in the binding file to precise the position for the person ? Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Migrating Cocoon 2.1 project to Cocoon 2.2
On Jul 27, 2008, at 4:30 PM, Barbara Slupik wrote: In cocoon-2.2 everything runs as blocks [...] Vadim Gritsenko replies: I have to point out that it's not quite true and in reality there are other alternatives [1]. [1] http://blog.reverycodes.com/archives/45.html Vadim's paper is very liberating! In fact, I've been working with his ideas since it was published last year. Cocoon 2.2 has changed quite bit for users since the paper was published. Here is an attempt to make his methods easy to try while retaining the ability to use blocks where appropriate. http://www.csparks.com/c22without.xhtml -Hugh Sparks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2 flowscipt debugger possible?
> Robin Wyles writes: [...] So my question should the FlowScript debugger really be enabled by default for dev mode? Grzegorz Kossakowski replies: Could you elaborate on these issues you face? If there are some serious problems then I think we'll switch it off again. Actually, you can do it yourself very easily but still defaults are important. Joy! (It works.) It is so easy to turn on and off now, I prefer to see it off by default even in dev mode. It is more trouble to fuss with the mode because you have to edit the pom and rebuild. But the property can can be changed after the webapp is deployed if needed. I tend to leave my jetty setup in mode dev all the time and the javaflow debugger is rather intrusive when not wanted. Thanks for the fix! I think this resolves JIRA COCOON-2221 -Hugh Sparks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can anyone let me know how to start build simple cocoon project .I am using jbuilder2008
Why not try the "getting started"? http://cocoon.apache.org/2.2/1159_1_1.html and then, as you encounter errors or problems, post them here so you can get help on specific issues. There *is* a lot to digest in Cocoon - but, like eating an elephant, best done one bite (byte?) at a time. >>> On 2008/08/04 at 06:47, in message <[EMAIL PROTECTED]>, "student csu" >>> <[EMAIL PROTECTED]> wrote: Can anyone let me know how to start build simple cocoon project .I am using jbuilder2008m . I am getting so many errors that I feel like I should start from beginning I am missing some concept. thanks -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: File upload
Not sure about the background processing part: it seems to me that your browser *is* still involved in the process ie. it is doing the sending while the server is doing the receiving... but this may help ito keeping the users informed: http://blog.fiveone.org/2006/11/good-progress.html http://ajaxian.com/archives/dojo-file-upload-progress-bar-widget >>> On 2008/08/04 at 05:44, in message <[EMAIL PROTECTED]>, "Magnus Haraldsen >>> Amundsen" <[EMAIL PROTECTED]> wrote: Hi, When doing file upload, and the file is at such a size that the processing of the uploaded file takes quite some time, is it possible to let the user continue with the browsing while the server handles the processing in the background? -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
