Craig McClanahan wrote:
> Ken Paulsen wrote:
>>
>>
>> Jacob Hookom wrote:
>>> I've played around with using ]]]]> in the response to escape nested
>>> CDATA sections before throwing them into the <async-response>-- it
>>> works, but as you process each rendered section, in JavaScript,
>>> you'll need to do: chunk.replace(']]]]>',']]>'), or strip the CDATA
>>> sections up front.
>> Right, but in this case the <script> tag is coming from Ed's
>> "AjaxZoneRenderer" and the writer in JSF is throwing in the CDATA
>> stuff. I am not modifying anything before the response is written...
>> and don't want to start doing that if I can avoid it. I also don't
>> want to modify his renderer / or JSF (obviously)...
>>
>> Anyway, after getting everything working, rebuilding the appserver in
>> a clean env. to try again... running into shale configuration
>> problems... I ended up modifying Ed's code to remove shale. The 30
>> lines of code that project saved wasn't worth while... I can already
>> ready resources out of a .jar in my project anyway. I would like to
>> work with Ed to make the resource resolution code plugable so I can
>> do this in a clean way. I saw your bug filed to remove the shale
>> dependency -- I agree this is a good idea considering the overhead /
>> configuration issues it causes.
> Was anyone planning on filing a bug or RFE against Shale describing
> whatever problems this causes you? Or are you guys just going to cut
> and run and reinvent the pieces of remoting that you need?
Of the 2 issues, one is already filed (remove dependency .jar files).
The other (mentioned above) relates to the following stack trace:
[#|2006-12-10T23:13:23.158-0800|INFO|sun-appserver-ee9.1|com.sun.jsftemplating|_ThreadID=12;_ThreadName=httpWorkerThread-8080-0;|WEBUI0004:
The requested resource
(/static/META-INF/libs/scriptaculous/version1.6.4/prototype.js) is not
available.|#]
[#|2006-12-10T23:13:23.159-0800|WARNING|sun-appserver-ee9.1|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=12;_ThreadName=httpWorkerThread-8080-0;_RequestID=1de3fe2b-e48e-435e-9976-ce30efc56ed4;|phase(RESTORE_VIEW
1,com.sun.faces.context.FacesContextImpl_at_594680) threw exception:
java.lang.NullPointerException null
org.apache.shale.remoting.impl.MappingImpl.viewId(MappingImpl.java:300)
org.apache.shale.remoting.impl.MappingImpl.mapViewId(MappingImpl.java:227)
org.apache.shale.remoting.faces.RemotingPhaseListener.afterPhase(RemotingPhaseListener.java:94)
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:278)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:398)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:255)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:186)
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556)
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1032)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556)
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1032)
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:250)
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:618)
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.processNonBlocked(DefaultProcessorTask.java:549)
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:790)
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:326)
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:248)
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:199)
com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
com.sun.enterprise.web.connector.grizzly.WorkerThreadImpl.run(WorkerThreadImpl.java:103)
|#]
I had accidentally missed the Dynamic Faces init parameter... I thought
it was related to that (note standard lifecycle above). But after
installing the init-param, clearing the generated directory in GF, and
restarting the whole server... I still had an exception from shale:
[#|2006-12-10T23:18:56.641-0800|INFO|sun-appserver-ee9.1|com.sun.jsftemplating|_ThreadID=12;_ThreadName=httpWorkerThread-8080-0;|WEBUI0004:
The requested resource
(/static/META-INF/libs/scriptaculous/version1.6.4/prototype.js) is not
available.|#]
[#|2006-12-10T23:18:56.642-0800|WARNING|sun-appserver-ee9.1|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=12;_ThreadName=httpWorkerThread-8080-0;_RequestID=4921981e-6383-4aa8-9655-f474eec508e3;|phase(RESTORE_VIEW
1,com.sun.faces.context.FacesContextImpl_at_b07848) threw exception:
java.lang.NullPointerException null
org.apache.shale.remoting.impl.MappingImpl.viewId(MappingImpl.java:300)
org.apache.shale.remoting.impl.MappingImpl.mapViewId(MappingImpl.java:227)
org.apache.shale.remoting.faces.RemotingPhaseListener.afterPhase(RemotingPhaseListener.java:94)
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:278)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
com.sun.faces.extensions.avatar.lifecycle.PartialTraversalLifecycle.execute(PartialTraversalLifecycle.java:79)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:398)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:255)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:186)
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556)
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1032)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556)
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1032)
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:250)
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:618)
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.processNonBlocked(DefaultProcessorTask.java:549)
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:790)
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:326)
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:248)
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:199)
com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
com.sun.enterprise.web.connector.grizzly.WorkerThreadImpl.run(WorkerThreadImpl.java:103)
I had it working at one point, I don't know if I did something to break
it or if it's intermittent. It might not be shale's fault, it may be
Dynamic Faces or the app server which has an error message on startup w/
the init-parm for Dynamic Faces in place:
[#|2006-12-10T23:24:08.654-0800|WARNING|sun-appserver-ee9.1|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=10;_ThreadName=main;_RequestID=82a8ab26-627d-4681-8565-5c574f07d7db;|LifecycleId
com.sun.faces.lifecycle.PARTIAL does not exist|#]
[#|2006-12-10T23:24:08.656-0800|SEVERE|sun-appserver-ee9.1|javax.enterprise.system.container.web|_ThreadID=10;_ThreadName=main;_RequestID=82a8ab26-627d-4681-8565-5c574f07d7db;|WebModule[]StandardWrapper.Throwable
java.lang.IllegalArgumentException: Cant create Lifecycle for id:
com.sun.faces.lifecycle.PARTIAL.
at
com.sun.faces.lifecycle.LifecycleFactoryImpl.getLifecycle(LifecycleFactoryImpl.java:226)
at javax.faces.webapp.FacesServlet.init(FacesServlet.java:170)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1165)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:994)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4689)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:5081)
at com.sun.enterprise.web.WebModule.start(WebModule.java:299)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1189)
at
org.apache.catalina.core.StandardHost.start(StandardHost.java:924)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1189)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:520)
at org.apache.catalina.startup.Embedded.start(Embedded.java:916)
at com.sun.enterprise.web.WebContainer.start(WebContainer.java:839)
at
com.sun.enterprise.web.PEWebContainer.startInstance(PEWebContainer.java:750)
Despite the error above, Dynamic Faces seemed to work (as you can see in
the prior stack trace, the DF lifecycle was used). If you'd like I can
file this... but I for now I have to finish my work for tomorrow's deadline.
Thanks!
Ken Paulsen
ken.paulsen_at_sun.com
https://jsftemplating.dev.java.net
>> I hope shale slims down and becomes easier to use... I like the
>> concept.
>>>
> Tell us what the problems are so we can address them.
> <http://issues.apache.org/struts>.
>
> Craig
>>> In any case, I do think that the best solution would be to move
>>> towards a packet-like convention, removing any formatting overhead
>>> and compressing the resulting response.
>> Yep, I liked your blog's proposal. I hope "Dynamic Faces" moves in
>> that direction.
>>
>> Ed, are you out there? What do you think?
>>
>> Ken Paulsen
>> ken.paulsen_at_sun.com
>> https://jsftemplating.dev.java.net
>>
>>>
>>> Ken Paulsen wrote:
>>>>
>>>> Some more info... if I switch Ed's code to text/html, the JS that
>>>> replaces the content is not recognized as XML (b/c it's not
>>>> anymore)... so nothing happens with the (now valid) response. So I
>>>> guess AjaxZones are broken for now unless there's work-a-round I
>>>> haven't thought of.
>>>>
>>>> In the mean time, fireAjaxRequest works as long as there aren't any
>>>> embedded CDATA sections -- such as those provided by JSF when
>>>> rendering any "Script" element (I still think this belongs at the
>>>> component level, not the writer level).
>>>>
>>>> Thanks!
>>>>
>>>> Ken Paulsen
>>>> ken.paulsen_at_sun.com
>>>> https://jsftemplating.dev.java.net
>>>>
>>>> Ken Paulsen wrote:
>>>>>
>>>>> Hi Jacob,
>>>>>
>>>>> I remember when Ryan made this change b/c I had to fix my
>>>>> ViewHandler to work with it. I had tried both text/html and
>>>>> application/xhtml+xml on the page w/o success. However, after
>>>>> your email, I looked into this more and found that Ed's
>>>>> PartialTraversalViewRoot sets the content-type to text/xml, which
>>>>> ends up being sent to the browser as application/xhtml+xml. I
>>>>> experience the problem in both the RI ViewHandler and mine. I
>>>>> could override the content-type in my ViewHandler, but I don't
>>>>> think it's a good idea to blindly override this... for now I think
>>>>> I'll change Ed's code to not return text/xml.
>>>>>
>>>>> Thanks for the help!
>>>>>
>>>>> Ken
>>>>>
>>>>> Jacob Hookom wrote:
>>>>>> The issue can be bypassed a bit by telling the RI's
>>>>>> ResponseWriter to not use XHTML by passing 'text/html' to the
>>>>>> RenderKit's constructor within your ViewHandler. This will
>>>>>> prevent the RI from forcing CDATA blocks around the script it
>>>>>> generates for commandLinks/etc.
>>>>>>
>>>>>> Although you are supposed to be able to 'escape' CDATA with
>>>>>> ']]]]>' for inner tails, it doesn't seem to be handled in the
>>>>>> browsers. More info on the problem here:
>>>>>>
>>>>>> http://weblogs.java.net/blog/jhook/archive/2006/12/ajax_responses.html
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ken Paulsen wrote:
>>>>>>>
>>>>>>> Hi Ed (or anyone else that knows),
>>>>>>>
>>>>>>> Are AjaxZones currently broken? I get "mismatched tag" errors
>>>>>>> on the partial response sent back from the server. I am using
>>>>>>> the latest version of JSF (1.2_03-b06-FCS), which may be
>>>>>>> contributing to the problem. It appears that the CDATA tags
>>>>>>> around the DynaFacesZones.ajaxifyChildren(...) in the response
>>>>>>> is causing the problem.
>>>>>>>
>>>>>>> Below is a JSP w/ a single button in an AjaxZone that
>>>>>>> demonstrates the problem.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Ken Paulsen
>>>>>>> ken.paulsen_at_sun.com
>>>>>>> https://jsftemplating.dev.java.net
>>>>>>>
>>>>>>>
>>>>>>> <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
>>>>>>> <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
>>>>>>> <%@ taglib prefix="jsfExt"
>>>>>>> uri="http://java.sun.com/jsf/extensions/dynafaces" %>
>>>>>>>
>>>>>>> <f:view>
>>>>>>> <html>
>>>>>>> <head>
>>>>>>> <title>DynaFaces JSP Blank App</title>
>>>>>>> <jsfExt:scripts />
>>>>>>> </head>
>>>>>>> <body bgcolor="white">
>>>>>>>
>>>>>>> <h:form id="form">
>>>>>>>
>>>>>>> <h1>DynaFaces JSP Blank App</h1>
>>>>>>>
>>>>>>> <jsfExt:ajaxZone id="zone1">
>>>>>>> <h:commandButton value="ZONE Request FOO" />
>>>>>>> </jsfExt:ajaxZone>
>>>>>>>
>>>>>>> </h:form>
>>>>>>>
>>>>>>> </body>
>>>>>>> </html>
>>>>>>> </f:view>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_jsf-extensions.dev.java.net
>>>>>>> For additional commands, e-mail:
>>>>>>> dev-help_at_jsf-extensions.dev.java.net
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_jsf-extensions.dev.java.net
>>>>>> For additional commands, e-mail:
>>>>>> dev-help_at_jsf-extensions.dev.java.net
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_jsf-extensions.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_jsf-extensions.dev.java.net
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_jsf-extensions.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_jsf-extensions.dev.java.net
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_jsf-extensions.dev.java.net
>>> For additional commands, e-mail: dev-help_at_jsf-extensions.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsf-extensions.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsf-extensions.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsf-extensions.dev.java.net
> For additional commands, e-mail: dev-help_at_jsf-extensions.dev.java.net
>