Hi Craig,
I submitted issue #360:
https://issues.apache.org/struts/browse/SHALE-360
FYI, I didn't cut and run and reinvent parts of shale. I had the
funtionality (loading resources from class files) written and used in
GlassFish before GlassFish was called GlassFish. I simply had to get my
work done and the current bugs I was encountering in shale (which I was
using b/c of Dynamic Faces) + the requirement of adding 2 additional jar
files which have to be staged in the GlassFish build env. etc... was
more than I could do before the deadline.
That said, I hope to re-take a look at shale when it's dependency list
isn't so long and more issues have been addressed... perhaps I can even
help address some of them.
Good luck and thanks!
Ken
Ken Paulsen wrote:
>
>
> 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
>>
>
> ---------------------------------------------------------------------
> 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
>