Craig McClanahan wrote:
> 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?
Nope. In this case it was commons-logging.jar. I'd rather not add any
jar to the application that isn't necessary. And the fewer # to track
version for, test for compatibility, etc., the better. I'm excited to
hear that shale remoting won't have any dependencies... that's a great
selling feature! ;)
One other thing I observed (and it may just be a perception), was that
the initial request for a shale remoting resource seemed to take a while
(I noticed it spit out log messages to the log file too when using
default log levels). I didn't run any performance #'s and my laptop
doesn't have enough memory to do the things I use it for... so
everything was running slow that night. :) Anyway, I don't have enough
information to file an RFE or bug for it... is startup time an issue
that has been raised or measured?
Thanks!
Ken
>> 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
>>
>
> ---------------------------------------------------------------------
> 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
>