Ken Paulsen wrote:
>
> Hi Craig,
>
> I submitted issue #360:
>
> https://issues.apache.org/struts/browse/SHALE-360
>
Thanks -- I'll look at that soon.
> 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.
>
Any help would be greatly appreciated! But, are there particular
dependencies that cause you grief? In particular, the only required
dependency for Shale Remoting is Commons Logging -- although I got
pushback from the other Shale developers on changing this to a hard
dependency on JDK 1.4 logging, I've got a strategy that should work to
make this optional if you are running on JDK 1.4. That will leave
Remoting just requiring JSF itself.
Post-Shale-1.0.3, we've also split up Shale into much finer grained
modules, with much improved Maven2 pom.xml files. Are there particular
sets of dependencies that are causing you concern?
> Good luck and thanks!
>
> Ken
Craig
>
> 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
>>
>
> ---------------------------------------------------------------------
> 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
>