Re: Error Handling
Tim, it's likely because the error happened during the rendering phase after the beginning of the HTML has already been flushed on the response socket... You have a couple of options: 1) move your offending code into prerender event and add an s:subview very high in your page markup so it's executed before a lot of markup is written on the socket, or 2) increase the page buffer size to be larger than the content before your exception is triggered, e.g. %@ page buffer=10kb % Hope it helps, -- Cyril Bouteille TravelMuse, Inc. Tim Corless wrote: I found that I have a NullPointerException in the my prerender code of my ViewController but I don't get an error page. I have set EXCEPTION_DISPATCH_PATH and it looks like when Shale does the redirect to my error page, the redirect causes an IllegalStateException. I have MyFaces default error handling on but I don't get an error page at all. Does anyone know how I get my error page to display? context-param param-nameorg.apache.shale.view.EXCEPTION_DISPATCH_PATH/param-name param-value/actions/app/Error.action/param-value /context-param [2009-05-05 08:39:27,566] [WebContainer : 20] *ERROR* org.apache.myfaces.lifecycle.PhaseListenerManager - Exception in PhaseListener RENDER_RESPONSE(6) afterPhase java.lang.IllegalStateException: Cannot forward. Response already committed. at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:157) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:425) at org.apache.shale.view.faces.ViewPhaseListener.afterPhaseExceptionCheck(ViewPhaseListener.java:202) Thanks -Tim smime.p7s Description: S/MIME Cryptographic Signature
Re: [ANNOUNCE] Apache Shale To Move To the Attic
It provides the missing C in MVC of JSF for GET requests. :-) A hook in the JSP where you can declare which managed bean should be initialized for rendering. Typically high in your JSP, s:subview id=name-of-your-bean would call NameOfYourBean.prerender() event. Each page is in control of what beans it needs w/o maintaining any additional mapping file or worry about URLs or having to recompile java on changes. It provides you also with the flexibility to do conditional initialization with verbatims etc. I'll check your link, thanks. It looks like the hook is the other direction with orchestra where the bean maps to JSPs. Kito Mann wrote: Hello Cyril, The Orchestra ViewController can definitely handle this. See: http://myfaces.apache.org/orchestra/myfaces-orchestra-core/viewController.html. I'm not too familiar with the s:subview tag -- how does that work? --- Kito D. Mann -- Author, JavaServer Faces in Action http://twitter.com/kito99 http://twitter.com/jsfcentral http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info +1 203-404-4848 x3 On Tue, Apr 28, 2009 at 5:39 PM, Cyril Bouteille cy...@travelmuse.com mailto:cy...@travelmuse.com wrote: Hi Kito, by VC feature I meant essentially the prerender event for processing GET requests. I couldn't see such hook from Orchestra's overview. Does it have such a feature? Writing custom PhaseListeners kicking in logic based on URLs gets a bit old... :) Shale's declarative s:subview id is great and much cleaner. Anything else like that out there? smime.p7s Description: S/MIME Cryptographic Signature
Re: [ANNOUNCE] Apache Shale To Move To the Attic
This is sad news! Can you please recommend alternative projects for migration of deployed View-Controller and Remote features? Thanks. Greg Reddin wrote: This is a heads up for the Shale user community that the Shale PMC has voted to move the project to the Attic. This means that the Shale developers (more formally its Project Management Committee) have voted to retire Shale and move the responsibility for its oversight over to the Attic project. The MyFaces community has expressed interest in continuing development of the Shale-Test module and the Shale PMC will work with MyFaces to migrate this piece of the codebase.. Look for further announcements to that regard in the near future. You can read more about the Apache Attic at http://attic.apache.org. You can follow the progress of the move at https://issues.apache.org/jira/browse/ATTIC-2 if you so wish. On behalf of the Apache Shale PMC, Thanks! Greg Reddin -- Cyril Bouteille VP, Engineering TravelMuse, Inc. smime.p7s Description: S/MIME Cryptographic Signature
Shale Remoting 1.0.4 not decoding HTTP param in UTF-8?
Hello, We seem to have a problem decoding HTTP params with Shale Remoting 1.0.4 + Sun App Server 9.1_02 w/ Mojarra 1.2_04-b22-p05. E.g. Občanská Plovárna gets decoded as Ob?anská Plovárna Note á gets decoded ok but not č although our sun-web-appparameter-encoding default-charset=utf-8/ The decoding is fine with standard JSP/JSF if we don't go through Shale Remoting. This looks very much like http://issues.apache.org/struts/browse/SHALE-282 but on the incoming/decoding side. Can anyone confirm if there is a similar issue with Shale parameter decoding on the request/reader side? Is there some sort of configuration setting we can set on Shale Remoting to make it decode parameters in UTF-8 w/o code change? Thanks! -- Cyril Bouteille VP, Engineering TravelMuse, Inc. 4410 El Camino Real, Suite 102 Los Altos, CA 94022 Site: http://www.travelmuse.com (RSS http://www.travelmuse.com/rss) | Cyril's TravelMuse http://www.travelmuse.com/profile/?mid=429 Blogs: Company http://www.travelmuse.com/community/blogs/travelmuse-company-blog (RSS http://www.travelmuse.com/community/blogs/travelmuse-company-blog/feeds/posts) | TravelMusings http://www.travelmuse.com/community/blogs/travel_musings (RSS http://www.travelmuse.com/community/blogs/travel_musings/feeds/posts) | Photo http://www.travelmuse.com/community/blogs/photography (RSS http://www.travelmuse.com/community/blogs/photography/feeds/posts) Facebook: Page http://www.new.facebook.com/pages/Los-Altos-CA/TravelMuse/12711960515?ref=ts | App http://apps.facebook.com/travelmuse/ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
Re: JSF 1.2 (MyFaces Core 1.2.x - implementation) Struts Shale
JSF 1.2 introduced @PostConstruct and @PreDestroy annotations (see http://weblogs.java.net/blog/jhook/archive/2007/05/jsf_12_ri_backi.html), which somewhat overlap with Shale's prerender/destroy hooks, but it's still not quite as powerful. Most notably: * @PostConstruct won't get call on every page it's used w/ a session-scoped FB, and * you can't control @PostConstruct execution everytime the FB is instanciated as Shale allows you to w/ s:subview does. I'm using JSF 1.2 Mojarra implementation w/ Shale just fine, but I unfortunately can't speak to MyFaces compatibility. Costa Basil wrote: I've been successfully using Struts Shale 1.0.3 with MyFaces 1.1.x Tomhawk 1.1.x. Now I want to upgrade to MyFaces Core 1.2.x which is a JSF 1.2 implementation. Can someone please tell me if JSF 1.2 makes some of features in Struts Shale Core obsolete - for instance the ViewController mechanism? Will Struts Shale work with MyFaces 1.2 seamlessly? My code is relying heavily on the shale framework (core) - all my managed beans extend the AbstractViewController class and rely on the ViewController calls made by the framework to prerender, init co. I am also using some of the validation tags. I didn't dig up the JSF 1.2 documentation but I think I read somewhere that JSF 1.2 offers something similar to the ViewController mechanism. Thanks __ Connect with friends from any web browser - no download required. Try the new Yahoo! Canada Messenger for the Web BETA at http://ca.messenger.yahoo.com/webmessengerpromo.php -- Cyril Bouteille VP, Engineering TravelMuse, Inc. 4410 El Camino Real, Suite 102 Los Altos, CA 94022 (f) 650-941-4751 http://www.travelmuse.com [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. smime.p7s Description: S/MIME Cryptographic Signature
Re: Broken URL's
smime.p7s Description: S/MIME Cryptographic Signature
Re: Broken URL's
Oops, sorry resending as plain text message: Cristi, I understand those taglib uris to be virtual only as unique keys for namespaces. They're not required to be a valid page for Shale or any other taglib. You can use tagdir=/WEB-INF/tags as an alternative to uris for your own tags, but I'm not sure it's going to help you here. We'd need more details about the actual issue you're experiencing to help. Cristi Magherusan wrote: Hello, I'm having a school project that must use shale, but it seems its taglibs uri's are broken links, among others. Please someone fix them, if possible. Also, is there a way to use local files instead of http:// links? Please use cc to send your answers to me since I'm not yet subscribed to the shale Mailing List. Thanks! Cristi smime.p7s Description: S/MIME Cryptographic Signature
Re: shale 1.0.4 in glassfish v2 classpath breaks admin webapp
smime.p7s Description: S/MIME Cryptographic Signature
Re: shale 1.0.4 in glassfish v2 classpath breaks admin webapp
.CoyoteAdapter.service(CoyoteAdapter.java:270) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:339) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:261) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:212) at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265) at com.sun.enterprise.web.connector.grizzly.WorkerThreadImpl.run(WorkerThreadImpl.java:116) |#] Cyril Bouteille wrote: Hello, We're using Shale 1.0.4 for a new JSF 1.2 web application inside Sun JSAS 9.1 (aka Glassfish V2) container. It seems the simple presence of shale classes in the shared classpath somehow interferes with the JSF administration console of Glassfish. When browsing pages of this web application, org.apache.shale.remoting.faces.MappingsHelper can't initialize properly and keeps blowing up on the error below. I'd think Shale's presence shouldn't interfere with JSF applications not installing its filters/listerners. Is RemotingPhaseListener somehow sneaking in when it shouldn't? Or should it be in watch-only mode and this is a bug? I found http://issues.apache.org/struts/browse/SHALE-360 to be related, but I don't really understand the workarounds being discussed nor why I should have to change the config of a 3rd-party web app, because I've Shale in the classpath for my own web apps... Could a developer please help me shed light on what is happening here? Thank you, [#|2007-10-01T16:37:07.965-0700|INFO|sun-appserver9.1|org.apache.shale.remoting.faces.MappingsHelper|_ThreadID=14;_ThreadName=httpWorkerThread-4848-0;|Configuring Mappings instance of type|#] [#|2007-10-01T16:37:07.966-0700|INFO|sun-appserver9.1|org.apache.shale.remoting.faces.MappingsHelper|_ThreadID=14;_ThreadName=httpWorkerThread-4848-0;|org.apache.shale.remoting.impl.MappingsImpl|#] [#|2007-10-01T16:37:07.967-0700|INFO|sun-appserver9.1|org.apache.shale.remoting.faces.MappingsHelper|_ThreadID=14;_ThreadName=httpWorkerThread-4848-0;|Configuring processor mapping|#] [#|2007-10-01T16:37:07.967-0700|INFO|sun-appserver9.1|org.apache.shale.remoting.faces.MappingsHelper|_ThreadID=14;_ThreadName=httpWorkerThread-4848-0;|/static/*:org.apache.shale.remoting.impl.ClassResourceProcessor|#] [#|2007-10-01T16:37:07.968-0700|INFO|sun-appserver9.1|org.apache.shale.remoting.faces.MappingsHelper|_ThreadID=14;_ThreadName=httpWorkerThread-4848-0;|Configuring processor mapping|#] [#|2007-10-01T16:37:07.968-0700|INFO|sun-appserver9.1|org.apache.shale.remoting.faces.MappingsHelper|_ThreadID=14;_ThreadName=httpWorkerThread-4848-0;|/dynamic/*:org.apache.shale.remoting.impl.MethodBindingProcessor|#] [#|2007-10-01T16:37:07.969-0700|INFO|sun-appserver9.1|org.apache.shale.remoting.faces.MappingsHelper|_ThreadID=14;_ThreadName=httpWorkerThread-4848-0;|Configuring processor mapping|#] [#|2007-10-01T16:37:07.969-0700|INFO|sun-appserver9.1|org.apache.shale.remoting.faces.MappingsHelper|_ThreadID=14;_ThreadName=httpWorkerThread-4848-0;|/webapp/*:org.apache.shale.remoting.impl.WebResourceProcessor|#] [#|2007-10-01T16:37:08.181-0700|WARNING|sun-appserver9.1|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=14;_ThreadName=httpWorkerThread-4848-0;_RequestID=57c77725-b321-48ae-8c30-952671dca4cb;|phase(RESTORE_VIEW 1,[EMAIL PROTECTED]) threw exception: java.lang.NullPointerException null org.apache.shale.remoting.faces.MappingsHelper.patterns(MappingsHelper.java:429) org.apache.shale.remoting.faces.MappingsHelper.createMappings(MappingsHelper.java:282) org.apache.shale.remoting.faces.MappingsHelper.getMappings(MappingsHelper.java:85) org.apache.shale.remoting.faces.RemotingPhaseListener.afterPhase(RemotingPhaseListener.java:102) com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:280) com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) com.sun.faces.extensions.avatar.lifecycle.PartialTraversalLifecycle.execute(PartialTraversalLifecycle.java:80) javax.faces.webapp.FacesServlet.service(FacesServlet.java:244) com.sun.enterprise.tools.admingui.servlet.DelayedInitFacesServlet.service(DelayedInitFacesServlet.java:89) org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:317) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:240
shale 1.0.4 in glassfish v2 classpath breaks admin webapp
smime.p7s Description: S/MIME Cryptographic Signature
[JSF] How to control scheme with commandLink/Button tags?
Hi, I've a problem using JSF/Shale on Sun AS 9.0.1 when deployed behind an SSL accelerator in production. Because secure requests get to the app server unencrypted, I am unable to use regular declarative security user-data-constraint/transport-guarantee/CONFIDENTIAL in web.xml, or it gets in an infinite loop redirecting to https... Anyway, so in the meantime, I'd just like to control the schemes on my links and action post, but JSF doesn't seem to support it! commandLink/Buttons don't seem to allow you to change scheme. If you put a full URL in the action, it fails to find the full URL w/ scheme in the faces-config.xml... Is this a Glassfish bug or a JSF oversight? Or am I missing some other way to programmatically control the scheme of a JSF command? I'd appreciate any workaround idea the community would be willing to share. :) Thank you,
Re: Shale incompatibility with Glassfish
Hi Craig, Is there anything you could recommend us to try or any information we could provide you to help figure out the incompatibility with the latest glassfish v1 JSF implementation? Also, as a temp workaround for us, is it safe/ok to use remoting w/o shale-core in our classpath? It seems to work... Thanks, Craig McClanahan wrote: On 10/3/06, Paul Tabor [EMAIL PROTECTED] wrote: There appears to be at least two issues with the current incarnation of Shale with Glassfish v1ur1b12, b13, b14 / JSF 1.2_02-b03-FCS. This problem has been verified with Shale 1.0.2, 1.0.3, and nightly build 20060926. 1) f:param's and jsp:param's do not get passed to the request parameters. 2) c:forEach appears to be broken when using a deferred value for the items attribute. The iteration works fine with Tomahawk t:dataList and with a standard h:dataTable. In both cases, the problems persist if the shale-core.jar is on the classpath. If we remove the shale-core.jar from our classpath, the c:forEach and f:param/jsp:param work fine. Would this have something to do with Shale's use of ValueBinding versus JSF 1.2's ValueExpression? From our experience with JSF 1.2 in Creator, I suspect this isn't the problem area ... the backwards compatibility seems to be quite good. I do suspect that this has sometthing to do with the changes in the way that the component tree is prebuilt (for JSP views) in JSF 1.2, versus the way they were built as the components were rendered in JSF 1.1. That's going to take some research to untangle. Craig
