>From: "Richard Eggert" <[EMAIL PROTECTED]> 
>
> I am using the ShaleApplicationFilter. I know it's being called, since it 
> ShaleApplicationFilter.doFilter appears in the stack trace for the error that 
> I'm getting. My chain-config.xml looks identical to the one from the 
> clay-usecases example (minus the commented-out parts). I have a ChainListener 
> configured and I have chain.CONFIG_WEB_RESOURCE pointing to 
> /WEB-INF/chain-config.xml. Is it possible that the MyFaces ExtensionsFilter 
> is 
> somehow interfering with it? If so, is there any way to remedy it? 
> 


Sorry, I was focusing on the wrong problem before.  It look like this 
getContentType() method is only available in the servlet 2.4.

http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletResponse.html#getContentType()



> Rich Eggert 
> Member of Technical Staff 
> Proteus Technologies, LLC 
> http://www.proteus-technologies.com 
> 

Gary

> 
> 
> -----Original Message----- 
> From: Gary VanMatre [mailto:[EMAIL PROTECTED] 
> Sent: Mon 2/26/2007 11:49 AM 
> To: user@shale.apache.org 
> Subject: Re: Weird error for full HTML views 
> 
> >From: "Richard Eggert" 
> > 
> > I'm trying to get full HTML views working. I was able to get partial HTML 
> views 
> > (using JSP to load the HTML template) working, but I keep getting the same 
> weird 
> > error: 
> > 
> 
> The full html and full xml views are different animals. If you are using a 
> full 
> HTML view, it must be a physical file similar to JSP. The full XML views 
> allow 
> you to define a config definition as the page entry point but it requires a 
> unique suffix. The default suffix is .html and .xml but can be changed in the 
> web.xml 
> 
> > java.lang.NoSuchMethodError: 
> > javax.servlet.http.HttpServletResponse.getContentType()Ljava/lang/String; 
> > at 
> > org.apache.shale.faces.ClayViewHandler.renderView(ClayViewHandler.java:385) 
> > ... 
> > 
> > 
> > The page I'm trying to load is named /htmlTest.foo and it exists only 
> > within 
> my 
> > clay-views.xml. I've set FULLXML_CONFIG_FILES to /WEB-INF/clay-views.xml. 
> > I've 
> > set XML_TEMPLATE_SUFFIX to .foo. I have a filter-mapping for /* to point to 
> the 
> > ShaleApplicationFilter that I set up. I have a servlet-mapping that maps 
> > *.foo 
> > to the Faces servlet. I have a mime-mapping that maps the "foo" extension 
> > to 
> > "text/html". I have not modified javax.faces.DEFAULT_SUFFIX (i.e., I've 
> > left 
> it 
> > as the default of ".jsp"), since I still have a lot of traditional 
> > JSP-based 
> JSF 
> > pages (I did try changing it to ".foo" at one point, to no effect). 
> > 
> > I don't know if it's relevant, but I did notice the following lines in my 
> > log 
> > file (note the file extensions): 
> > org.apache.shale.clay.faces.ClayViewHandler:282 - Clay template restoreView 
> for 
> > /htmlTest.jsp 
> > org.apache.shale.clay.faces.ClayViewHandler:366 - Clay template renderView 
> > for 
> > /htmlTest.jsp 
> > 
> > Does anyone have any idea of why I'm getting this error (or, more 
> > importantly, 
> > how to fix it)? 
> > 
> 
> JSF really only wants you to choose one type of templating. You can mix the 
> three types but you need the shale-application library. What happens is JSF 
> will normalize the view suffix to the javax.faces.DEFAULT_SUFFIX value. There 
> is a preprocess command that is invoked from a filter that captures the view 
> suffix before the normal processing of the viewId. The captured suffix 
> overrides the default. This won't work in a portal environment and I've heard 
> reports of it not working all the time. 
> 
> I covered this in more detail in a resonse to Bernhard's question [1]. The 
> shale-clay-usecases trys to explain the problems too [2]. 
> 
> 
> Unfortunately, you are better off if you choose a single JSF view entry 
> point. 
> 
> [1] http://www.nabble.com/Clay-templating-tf3292202.html (should be here but 
> I 
> just posted the response) 
> [2] 
> https://svn.apache.org/viewvc/shale/framework/trunk/shale-apps/shale-clay-usecas
>  
> es/src/main/webapp/usecases.jsp?view=markup 
> 
> 
> 
> > 
> > Rich Eggert 
> > Member of Technical Staff 
> > Proteus Technologies, LLC 
> > http://www.proteus-technologies.com 
> > 
> > 
> > 
> 
> 

Reply via email to