Re: Updated version of TilesViewHandler
If you are willing to use JSF RI 1.2 (not MyFaces), then I posted an
experimental version as an attachment at:
http://issues.apache.org/struts/browse/SHALE-302
-=> Gregg <=-
Garner, Shawn wrote:
> Since the release of a GA version of Standalone Tiles when can we expect
> a new version of the TilesViewHandler compatible with 2.0.5 of
> standalone tiles?
>
> I tried the current one with 2.0.5 and got no class def found
> exceptions.
>
>
> Shawn
>
>
> -Message Disclaimer-
>
> This e-mail message is intended only for the use of the individual or
> entity to which it is addressed, and may contain information that is
> privileged, confidential and exempt from disclosure under applicable law.
> If you are not the intended recipient, any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> reply email to [EMAIL PROTECTED] and delete or destroy all copies of
> the original message and attachments thereto. Email sent to or from the
> Principal Financial Group or any of its member companies may be retained
> as required by law or regulation.
>
> Nothing in this message is intended to constitute an Electronic signature
> for purposes of the Uniform Electronic Transactions Act (UETA) or the
> Electronic Signatures in Global and National Commerce Act ("E-Sign")
> unless a specific statement to the contrary is included in this message.
>
> While this communication may be used to promote or market a transaction
> or an idea that is discussed in the publication, it is intended to provide
> general information about the subject matter covered and is provided with
> the understanding that The Principal is not rendering legal, accounting,
> or tax advice. It is not a marketed opinion and may not be used to avoid
> penalties under the Internal Revenue Code. You should consult with
> appropriate counsel or other advisors on all matters pertaining to legal,
> tax, or accounting obligations and requirements.
>
>
signature.asc
Description: OpenPGP digital signature
Re: SV: Tiles integration
I have attached the TilesViewHandler source to the existing bug report at: https://issues.apache.org/struts/browse/SHALE-302 I granted ASF Works inclusion, but Sun com package code is involved, so you may have to sort the licensing issues out depending on what you do with it. For those developers who are using the Shale API versus developing it, if you wish to use this code to work with Tiles, JSF 1.2 RI and Shale, feel free to do so, but note that it is completely experimental non-production level code and you use it at your own risk. -=> Gregg <=- Greg Reddin wrote: > On 10/4/07, Gregg Leichtman <[EMAIL PROTECTED]> wrote: > >> If there is interest I would be happy to post it as a JIRA item. >> > > > Please do :-) > > Greg > > signature.asc Description: OpenPGP digital signature
Re: SV: Tiles integration
Sorry I didn't reply to this earlier, but I didn't see it until now. I did not do this, because the code is RI specific. It uses a number of Sun com classes in the imports for example. When I posted this previously on 7/25 under topic: "Any sucess with shale nightly 20070717 and RI JSF 1.2?", Mr. VanMatre correctly pointed this out and I just thought that this meant that the Shale developers would rather just go their own way rather than use anything from this code. I have been using this view handler since that time and have not had problems with it. I'm using Tiles 2.0.4, Trinidad 1.2.1, Tomahawk 1.1.6, dojo 0.9, shale 1.1.0 snapshot 20070923. I haven't used much of Shale yet, just really Tiles so far and I haven't mixed in Spring or Hibernate, since I have not gotten to that part in my dev effort so I can not speak to them yet. If there is interest I would be happy to post it as a JIRA item. -=> Gregg <=- > Antonio Petrelli wrote: > >> Gregg, why don't you post your work as a patch in JIRA? >> If you cannot find the right issue, open a new one. Anyway good candidates >> are: >> https://issues.apache.org/struts/browse/SHALE/component/21281 >> >> Antonio >> >> 2007/9/13, Gregg Leichtman <[EMAIL PROTECTED]>: >> >> >>> I was not successful in getting the webapp stack that you mention to >>> work. I ended up modifying an old TilesViewHandler to work with JSF 1.2 >>> RI v1.2_04-b16-p02, not MyFaces, a nightly snapshot of Shale 1.1.0 from >>> July 17, 2007, the released version of Trinidad 1.2.1, Tomahawk 1.1.6, >>> JSTL 1.1.2 and Tiles 2.0.4. The view handler has worked well for me so >>> far, (I'm still just developing my webapp with it) so if you're willing >>> to use this experimental version along with the RI until these issues >>> are resolved, you can find a posted copy of the source code at: >>> >>> >>> >>> http://www.nabble.com/Any-sucess-with-shale-nightly-20070717-and-RI-JSF-1.2--tf4123632.html#a11784014 >>> >>> -=> Gregg <=- >>> >>> Hermod Opstvedt wrote: >>> >>> >>>> Hi >>>> >>>> I don't think think MyFaces 1.2 is compatible with that Tiles version - >>>> >>>> >>> Ask >>> >>> >>>> on the MyFaces list. >>>> >>>> Hermod >>>> >>>> -Opprinnelig melding- >>>> Fra: Edward Dowgiallo [mailto:[EMAIL PROTECTED] >>>> Sendt: 28. august 2007 21:31 >>>> Til: user@shale.apache.org >>>> Emne: Fwd: Tiles integration >>>> >>>> -- Forwarded message -- >>>> From: Edward Dowgiallo <[EMAIL PROTECTED]> >>>> Date: Aug 28, 2007 3:20 PM >>>> Subject: Tiles integration >>>> To: [EMAIL PROTECTED] >>>> >>>> I'm trying to get the following combination running: >>>> >>>>- MyFaces 1.2.0 >>>>- Shale Tiles 1.0.4 >>>>- Trinidad 1.2.1 >>>> >>>> Willing to try other combinations, especially if someone has a >>>> blank.warhandy. Been at this for about 7 hours now. >>>> >>>> Getting the following exception: >>>> >>>> java.lang.IllegalStateException: Cannot create a session after the >>>> >>>> >>> response >>> >>> >>>> has been committed >>>> >>>> org.apache.catalina.connector.Request.doGetSession(Request.java:2301) >>>> >>>> org.apache.catalina.connector.Request.getSession(Request.java >>>> >>>> >>> :2075) >>> >>> >>>> org.apache.catalina.connector.RequestFacade.getSession( >>>> >>>> >>> RequestFacade.java:83 >>> >>> >>>> 3) >>>> >>>> org.apache.myfaces.context.servlet.ServletExternalContextImpl.getSession >>>> (ServletExternalContextImpl.java:117) >>>> >>>> org.apache.myfaces.trinidad.context.ExternalContextDecorator.getSession >>>> >>>> >>> (Exte >>> >>> >>>> rnalContextDecorator.java:92) >>>> >>>> org.apache.myfaces.trinidad.context.ExternalCon
Re: SV: Tiles integration
Sorry I didn't reply to this earlier, but I didn't see it until now. I did not do this, because the code is RI specific. It uses a number of Sun com classes in the imports for example. When I posted this previously on 7/25 under topic: "Any sucess with shale nightly 20070717 and RI JSF 1.2?", Mr VanMatre correctly pointed this out and I just thought that this meant that the Shale developers would rather just go their own way rather than use anything from this code. I have been using this view handler since that time and have not had problems with it. I'm using Tiles 2.0.4, Trinidad 1.2.1, Tomahawk 1.1.6, dojo 0.9, shale 1.1.0 snapshot 20070923. Haven't used much of Shale yet, just really Tiles so far and haven't mixed in Spring or Hibernate, since I have not gotten to that part in my dev effort so I can speak to them yet. If there is interest I would be happy to post it as a JIRA item. -=> Gregg <=- Antonio Petrelli wrote: > Gregg, why don't you post your work as a patch in JIRA? > If you cannot find the right issue, open a new one. Anyway good candidates > are: > https://issues.apache.org/struts/browse/SHALE/component/21281 > > Antonio > > 2007/9/13, Gregg Leichtman <[EMAIL PROTECTED]>: > >> I was not successful in getting the webapp stack that you mention to >> work. I ended up modifying an old TilesViewHandler to work with JSF 1.2 >> RI v1.2_04-b16-p02, not MyFaces, a nightly snapshot of Shale 1.1.0 from >> July 17, 2007, the released version of Trinidad 1.2.1, Tomahawk 1.1.6, >> JSTL 1.1.2 and Tiles 2.0.4. The view handler has worked well for me so >> far, (I'm still just developing my webapp with it) so if you're willing >> to use this experimental version along with the RI until these issues >> are resolved, you can find a posted copy of the source code at: >> >> >> >> http://www.nabble.com/Any-sucess-with-shale-nightly-20070717-and-RI-JSF-1.2--tf4123632.html#a11784014 >> >> -=> Gregg <=- >> >> Hermod Opstvedt wrote: >> >>> Hi >>> >>> I don't think think MyFaces 1.2 is compatible with that Tiles version - >>> >> Ask >> >>> on the MyFaces list. >>> >>> Hermod >>> >>> -Opprinnelig melding- >>> Fra: Edward Dowgiallo [mailto:[EMAIL PROTECTED] >>> Sendt: 28. august 2007 21:31 >>> Til: user@shale.apache.org >>> Emne: Fwd: Tiles integration >>> >>> -- Forwarded message -- >>> From: Edward Dowgiallo <[EMAIL PROTECTED]> >>> Date: Aug 28, 2007 3:20 PM >>> Subject: Tiles integration >>> To: [EMAIL PROTECTED] >>> >>> I'm trying to get the following combination running: >>> >>>- MyFaces 1.2.0 >>>- Shale Tiles 1.0.4 >>>- Trinidad 1.2.1 >>> >>> Willing to try other combinations, especially if someone has a >>> blank.warhandy. Been at this for about 7 hours now. >>> >>> Getting the following exception: >>> >>> java.lang.IllegalStateException: Cannot create a session after the >>> >> response >> >>> has been committed >>> >>> org.apache.catalina.connector.Request.doGetSession(Request.java:2301) >>> >>> org.apache.catalina.connector.Request.getSession(Request.java >>> >> :2075) >> >>> org.apache.catalina.connector.RequestFacade.getSession( >>> >> RequestFacade.java:83 >> >>> 3) >>> >>> org.apache.myfaces.context.servlet.ServletExternalContextImpl.getSession >>> (ServletExternalContextImpl.java:117) >>> >>> org.apache.myfaces.trinidad.context.ExternalContextDecorator.getSession >>> >> (Exte >> >>> rnalContextDecorator.java:92) >>> >>> org.apache.myfaces.trinidad.context.ExternalContextDecorator.getSession >>> (ExternalContextDecorator.java:92) >>> >>> >>> >> org.apache.myfaces.trinidadinternal.util.TokenCache.getTokenCacheFromSession >> >>> (TokenCache.java:72) >>> >>> >>> >> org.apache.myfaces.trinidadinternal.application.StateManagerImpl._getViewCac >> >>> he(StateManagerImpl.java >>> :548) >>> >>> >>> >> org.apache.myfaces.trinidadinternal.application.StateManagerImpl.saveSeriali >> >>> zedView(
Re: SV: Tiles integration
signature.asc Description: OpenPGP digital signature
Re: SV: Tiles integration
I was not successful in getting the webapp stack that you mention to work. I ended up modifying an old TilesViewHandler to work with JSF 1.2 RI v1.2_04-b16-p02, not MyFaces, a nightly snapshot of Shale 1.1.0 from July 17, 2007, the released version of Trinidad 1.2.1, Tomahawk 1.1.6, JSTL 1.1.2 and Tiles 2.0.4. The view handler has worked well for me so far, (I'm still just developing my webapp with it) so if you're willing to use this experimental version along with the RI until these issues are resolved, you can find a posted copy of the source code at: http://www.nabble.com/Any-sucess-with-shale-nightly-20070717-and-RI-JSF-1.2--tf4123632.html#a11784014 -=> Gregg <=- Hermod Opstvedt wrote: > Hi > > I don't think think MyFaces 1.2 is compatible with that Tiles version - Ask > on the MyFaces list. > > Hermod > > -Opprinnelig melding- > Fra: Edward Dowgiallo [mailto:[EMAIL PROTECTED] > Sendt: 28. august 2007 21:31 > Til: user@shale.apache.org > Emne: Fwd: Tiles integration > > -- Forwarded message -- > From: Edward Dowgiallo <[EMAIL PROTECTED]> > Date: Aug 28, 2007 3:20 PM > Subject: Tiles integration > To: [EMAIL PROTECTED] > > I'm trying to get the following combination running: > >- MyFaces 1.2.0 >- Shale Tiles 1.0.4 >- Trinidad 1.2.1 > > Willing to try other combinations, especially if someone has a > blank.warhandy. Been at this for about 7 hours now. > > Getting the following exception: > > java.lang.IllegalStateException: Cannot create a session after the response > has been committed > > org.apache.catalina.connector.Request.doGetSession(Request.java:2301) > > org.apache.catalina.connector.Request.getSession(Request.java:2075) > > org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:83 > 3) > > org.apache.myfaces.context.servlet.ServletExternalContextImpl.getSession > (ServletExternalContextImpl.java:117) > > org.apache.myfaces.trinidad.context.ExternalContextDecorator.getSession(Exte > rnalContextDecorator.java:92) > > org.apache.myfaces.trinidad.context.ExternalContextDecorator.getSession > (ExternalContextDecorator.java:92) > > org.apache.myfaces.trinidadinternal.util.TokenCache.getTokenCacheFromSession > (TokenCache.java:72) > > org.apache.myfaces.trinidadinternal.application.StateManagerImpl._getViewCac > he(StateManagerImpl.java > :548) > > org.apache.myfaces.trinidadinternal.application.StateManagerImpl.saveSeriali > zedView(StateManagerImpl.java:265) > javax.faces.application.StateManager.saveView(StateManager.java:47) > > org.apache.myfaces.application.jsp.JspViewHandlerImpl$StateMarkerAwareWriter > .flushToWriter > (JspViewHandlerImpl.java:387) > > org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHand > lerImpl.java:322) > > javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.jav > a:45) > > org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView > (ViewHandlerImpl.java:174) > > org.apache.shale.tiles.TilesViewHandler.renderView(TilesViewHandler.java:176 > ) > > javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.jav > a:45) > > org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView > (ViewHandlerImpl.java:174) > > org.apache.shale.tiles.TilesViewHandler.renderView(TilesViewHandler.java:176 > ) > > org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseEx > ecutor.java:41) > org.apache.myfaces.lifecycle.LifecycleImpl.render > (LifecycleImpl.java:132) > javax.faces.webapp.FacesServlet.service(FacesServlet.java:138) > > tiles-defs.xml > > > > > > > > > > > > > > > > > > > faces-config.xml > >xmlns="http://java.sun.com/xml/ns/javaee > " > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee > http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd"; > version="1.2"> > > > > > > org.apache.shale.tiles.TilesViewHandler > > > > > web.xml > > http://www.w3.org/2001/XMLSchema-instance"; > xmlns="http://java.sun.com/xml/ns/javaee"; > xmlns:web=" > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"; > > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"; > id="WebApp_ID" > version="2.5"> > tiles > > > > index.html > index.htm > index.jsp > > default.html > default.htm > default.jsp > > > > > javax.faces.STATE_SAVING_METHOD > client > > S
Re: Any sucess with shale nightly 20070717 and RI JSF 1.2?
For those who wish to _experiment_ with JSF 1.2 RI ( created using
version 1.2_04p2 from Sun) only (MyFaces is not supported in this
code), here is an updated TilesViewHandler class as I modified it to
work with Tiles 2.0.4 (the latest released version as of this date).
Clearly, the code is far from production usable and I make no claims
to it or its usability for any purpose, but it does potentially
provide a bridge, for me at least, to use JSF 1.2 in my development
effort while I wait for the production version from the experts. :-)
I politely request that you do not ask for help with this code from
the Shale or Tiles developers if you use it, since it is not released
by either development group. In addition my interest in this code
extends to its ability to support my needs, so I currently do not
intend to support it beyond any issues I run into in my development
efforts prior to release of an official Shale version.
-=> Gregg <=-
-- TilesViewHandler.java
package org.apache.shale.tiles;
import com.sun.faces.RIConstants;
import com.sun.faces.config.WebConfiguration;
import com.sun.faces.config.WebConfiguration.WebContextInitParameter;
import com.sun.faces.io.FastStringWriter;
import com.sun.faces.util.DebugUtil;
import com.sun.faces.util.MessageUtils;
import com.sun.faces.util.Util;
import com.sun.faces.application.InterweavingResponse;
//import com.sun.faces.application.ApplicationAssociate;
import com.sun.faces.application.ViewHandlerResponseWrapper;
import javax.faces.FacesException;
import javax.faces.FactoryFinder;
import javax.faces.application.StateManager;
import javax.faces.application.ViewHandler;
import javax.faces.component.UIViewRoot;
import javax.faces.context.ExternalContext;
import javax.faces.context.FacesContext;
import javax.faces.context.ResponseWriter;
import javax.faces.render.RenderKit;
import javax.faces.render.RenderKitFactory;
import javax.faces.render.ResponseStateManager;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.jsp.jstl.core.Config;
import java.io.IOException;
import java.io.Writer;
import java.text.MessageFormat;
import java.util.Iterator;
import java.util.Locale;
import java.util.MissingResourceException;
import java.util.ResourceBundle;
import java.util.Map;
import java.util.logging.Level;
import java.util.logging.Logger;
import org.apache.tiles.context.BasicAttributeContext;
import org.apache.tiles.Definition;
import org.apache.tiles.definition.Definitions;
import org.apache.tiles.definition.DefinitionsFactory;
import org.apache.tiles.definition.UrlDefinitionsFactory;
import org.apache.tiles.definition.DefinitionsFactoryException;
import org.apache.tiles.access.TilesAccess;
import org.apache.tiles.TilesContainer;
import org.apache.tiles.impl.BasicTilesContainer;
import org.apache.tiles.context.ChainedTilesContextFactory;
import org.apache.tiles.context.TilesRequestContext;
import org.apache.tiles.context.TilesContextFactory;
public class TilesViewHandler extends ViewHandler {
// -
Constructor
/**
* Stores the reference to the default view handler for later
use.
*
* @param defaultViewHandler The default view handler
*/
public TilesViewHandler(ViewHandler defaultViewHandler) {
this.defaultViewHandler = defaultViewHandler;
if (logger.isLoggable(Level.FINE)) {
logger.log(Level.FINE,"Created ViewHandler instance ");
}
}
// Static
Variables
/**
* MessageFormat used to perform parameter
substitution.
*/
private MessageFormat format = new MessageFormat("");
/**
* Message resources for this class.
*/
private static ResourceBundle bundle =
ResourceBundle.getBundle("org.apache.shale.tiles.Bundle",
Locale.getDefault(),
TilesViewHandler.class.getClassLoader());
/**
* The default JSF view handler.
*/
private ViewHandler defaultViewHandler = null;
// -
ViewHandler Methods
// Log instance for this class
private static final Logger logger = Util.getLogger(Util.FACES_LOGGER
+
Util.APPLICATION_LOGGER);
private static final String AFTER_VIEW_CONTENT =
RIConstants.FACES_PREFIX+
"AFTER_VIEW_CONTENT";
//private ApplicationAssociate associate;
/**
* Store the value of DEFAULT_SUFFIX_PARAM_NAME
* or, if that isn't defined, the value of DEFAULT_SUFFIX
*/
private String contextDefaultSuffix;
private int bufSize = -1;
public String calculateRenderKitId(FacesContext context) {
if (context == null) {
String message = MessageUtils.getException
Re: Any sucess with shale nightly 20070717 and RI JSF 1.2?
signature.asc Description: OpenPGP digital signature
Re: Any sucess with shale nightly 20070717 and RI JSF 1.2?
r stateBuilder = state.getBuffer();
int stateLen = stateBuilder.length();
int pos = 0;
int tildeIdx = getNextDelimiterIndex(builder, pos);
while (pos < totalLen) {
if (tildeIdx != -1) {
if (tildeIdx > pos && (tildeIdx - pos) > bufSize) {
// theres enough content before the first ~
// to fill the entire buffer
builder.getChars(pos, (pos + bufSize), buf, 0);
orig.write(buf);
pos += bufSize;
} else {
// write all content up to the first '~'
builder.getChars(pos, tildeIdx, buf, 0);
int len = (tildeIdx - pos);
orig.write(buf, 0, len);
// now check to see if the state saving string is
// at the begining of pos, if so, write our
// state out.
if (builder.indexOf(
RIConstants.SAVESTATE_FIELD_MARKER,
pos) == tildeIdx) {
// buf is effectively zero'd out at this point
int statePos = 0;
while (statePos < stateLen) {
if ((stateLen - statePos) > bufSize) {
// enough state to fill the buffer
stateBuilder.getChars(statePos,
(statePos + bufSize),
buf,
0);
orig.write(buf);
statePos += bufSize;
} else {
int slen = (stateLen - statePos);
stateBuilder.getChars(statePos,
stateLen,
buf,
0);
orig.write(buf, 0, slen);
statePos += slen;
}
}
// push us past the last '~' at the end of the marker
pos += (len + STATE_MARKER_LEN);
tildeIdx = getNextDelimiterIndex(builder, pos);
} else {
pos = tildeIdx;
tildeIdx = getNextDelimiterIndex(builder,
tildeIdx + 1);
}
}
} else {
// we've written all of the state field markers.
// finish writing content
if (totalLen - pos > bufSize) {
// there's enough content to fill the buffer
builder.getChars(pos, (pos + bufSize), buf, 0);
orig.write(buf);
pos += bufSize;
} else {
// we're near the end of the response
builder.getChars(pos, totalLen, buf, 0);
int len = (totalLen - pos);
orig.write(buf, 0, len);
pos += (len + 1);
}
}
}
}
private static int getNextDelimiterIndex(StringBuilder builder,
int offset) {
return builder.indexOf(RIConstants.SAVESTATE_FIELD_DELIMITER,
offset);
}
}
}
-- end TilesViewHandler.java
Gary VanMatre wrote:
> >Sorry about the empty post. Let's try again.
> >
> >There appears to be an unresolved bug from 02/Oct/06 reported against
> >this problem along with a workaround at:
> >https://issues.apache.org/struts/browse/SHALE-302
> >http://forum.java.sun.com/thread.jspa?threadID=770686&messageID=4408064
> <http://forum.java.sun.com/thread.jspa?threadID=770686&messageID=4408064>
> >
> > -=> Gregg <=-
>
> Gregg, thanks for providing more information. The issues that Shale
> has with regards to the proposed changes:
>
> * Shale doesn’t yet have a code branch specifically focusing on JSF
> 1.2. We have talked about doing this but have not made it a priority.
>
> * Shale tries to be RI neutral. The solution on the forum uses classes
> in the implementation of the Sun RI. This solution wouldn’t work with
> myfaces.
>
> Gary
>
>
>
>
> Subject:
> Re: Any sucess with shale nightly 20070717 and RI JSF 1.2?
> From:
> Gregg Leichtman <[EMAIL PROTECTED]>
> Date:
> Wed, 25 Jul 2007 04:10:34 +
> To:
> user@shale.apache.org
>
> To:
> user@shale.apache.org
>
>
> Sorry about the empty post. Let's try again.
>
> There appears to be an unresolved bug from 02/Oct/06 reported against
> this problem along with a workaround at:
> https://issues.apache.org/struts/browse/SHALE-302
> <http://forum.java.sun.com/thread.jspa?threadID=770686&messageID=4408064>
>
> -=> Gregg <=-
>
> Gregg Leichtman wrote:
>
>> I have assembled a small sample project using:
>> RI of JSF 1.2 v1.2_04_p2
>> Shale nightly 20070717
>> tiles-core-2.0-r468346-SNAPSHOT.jar from the Shale nightly distribution
>> JSTL 1.1.2
>> Tomcat 6.0.13
>> Updated the faces-config.xml to use:
>> http://java.sun.com/xml/ns/javaee";
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
>> http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd";
>> version="1.2">
>> Updated the web.xml to use:
>> > xmlns="http://java.sun.com/xml/ns/j2ee";
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
>> http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd";>
>>
>> I have the same sample project working successfully using:
>> myfaces 1.1.4
>> Shale nightly 20070409
>> tiles-core-2.0-r468346-SNAPSHOT.jar from the Shale nightly distribution
>> JSTL 1.1.2
>> Tomcat 6.0.13
>> faces-config.xml:
>> > "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN"
>> "http://java.sun.com/dtd/web-facesconfig_1_1.dtd";>
>> web.xml:
>> > xmlns="http://java.sun.com/xml/ns/j2ee";
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
>> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";>
>>
>> When I attempt to display the home page of the new project, I get a
>> blank page. I have checked the tomcat logs and there are no complaints.
>> The web page source from the page that is displayed consists only of:
>>
>>
>>
>>
>>
>> Using Live HTTP Headers inside FireFox yielded nothing of interest as
>> far as I can tell.
>>
>> Have I mixed incompatible components?
>>
>> If not does anyone have a suggestion short of debugging the JSF RI or
>> tiles source on how I can track down what is happening?
>>
>> -=> Gregg <=-
>>
>>
>>
>>
>>
>
>
signature.asc
Description: OpenPGP digital signature
Re: Any sucess with shale nightly 20070717 and RI JSF 1.2?
Sorry about the empty post. Let's try again. There appears to be an unresolved bug from 02/Oct/06 reported against this problem along with a workaround at: https://issues.apache.org/struts/browse/SHALE-302 <http://forum.java.sun.com/thread.jspa?threadID=770686&messageID=4408064> -=> Gregg <=- Gregg Leichtman wrote: > I have assembled a small sample project using: > RI of JSF 1.2 v1.2_04_p2 > Shale nightly 20070717 > tiles-core-2.0-r468346-SNAPSHOT.jar from the Shale nightly distribution > JSTL 1.1.2 > Tomcat 6.0.13 > Updated the faces-config.xml to use: > http://java.sun.com/xml/ns/javaee"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee > http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd"; > version="1.2"> > Updated the web.xml to use: >xmlns="http://java.sun.com/xml/ns/j2ee"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee > http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd";> > > I have the same sample project working successfully using: > myfaces 1.1.4 > Shale nightly 20070409 > tiles-core-2.0-r468346-SNAPSHOT.jar from the Shale nightly distribution > JSTL 1.1.2 > Tomcat 6.0.13 > faces-config.xml: > "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN" > "http://java.sun.com/dtd/web-facesconfig_1_1.dtd";> > web.xml: >xmlns="http://java.sun.com/xml/ns/j2ee"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";> > > When I attempt to display the home page of the new project, I get a > blank page. I have checked the tomcat logs and there are no complaints. > The web page source from the page that is displayed consists only of: > > > > > > Using Live HTTP Headers inside FireFox yielded nothing of interest as > far as I can tell. > > Have I mixed incompatible components? > > If not does anyone have a suggestion short of debugging the JSF RI or > tiles source on how I can track down what is happening? > > -=> Gregg <=- > > > > signature.asc Description: OpenPGP digital signature
Re: Any sucess with shale nightly 20070717 and RI JSF 1.2?
signature.asc Description: OpenPGP digital signature
Any sucess with shale nightly 20070717 and RI JSF 1.2?
I have assembled a small sample project using: RI of JSF 1.2 v1.2_04_p2 Shale nightly 20070717 tiles-core-2.0-r468346-SNAPSHOT.jar from the Shale nightly distribution JSTL 1.1.2 Tomcat 6.0.13 Updated the faces-config.xml to use: http://java.sun.com/xml/ns/javaee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd"; version="1.2"> Updated the web.xml to use: http://java.sun.com/xml/ns/j2ee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd";> I have the same sample project working successfully using: myfaces 1.1.4 Shale nightly 20070409 tiles-core-2.0-r468346-SNAPSHOT.jar from the Shale nightly distribution JSTL 1.1.2 Tomcat 6.0.13 faces-config.xml: http://java.sun.com/dtd/web-facesconfig_1_1.dtd";> web.xml: http://java.sun.com/xml/ns/j2ee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";> When I attempt to display the home page of the new project, I get a blank page. I have checked the tomcat logs and there are no complaints. The web page source from the page that is displayed consists only of: Using Live HTTP Headers inside FireFox yielded nothing of interest as far as I can tell. Have I mixed incompatible components? If not does anyone have a suggestion short of debugging the JSF RI or tiles source on how I can track down what is happening? -=> Gregg <=- signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature
Re: shale-tiger and jsf 1.2
There appear to be some problems with MyFaces 1.2.0 or Tomcat 6.0.13 and JSF tags. For example see: http://article.gmane.org/gmane.comp.jakarta.myfaces.user/38651 This does not address your specific problem, but I ran into the above referenced problem immediately. Notice that the problem was reported yesterday. -=> Gregg <=- Tomasz Pasierb wrote: > Hi, > > shale-tiger doesn't seem to work with myfaces 1.2 which has recenlty > been released. I have a bean annotated with @Bean and it doesn't seem > to be picked up. The bean doesn't exists when I try to get/set some > properties on it using EL. Everything is fine with the bean when it's > declared in faces-config.xml. > Additionally no messages are logged by tiger even on debug level apart > from the one that states that 'original variableResolver was wrapped...' > > Does shale-tiger work with jsf 1.2? (I've quickly skimmed through the > sources and it seems that only DTDs for jsf 1_0 and 1_1 are allowed > (FacesConfigParser#REGISTRATIONS) if that's what it's used for. I've > configured my webapp according to the jee5 tutorial where they use > schema for 1.2. May this be the reason why shale-tiger doesn't > register the annotated beans?) > > Regards, > Tom Pasierb > signature.asc Description: OpenPGP digital signature
Upgrade to new Tiles version
Do you plan to upgrade the unreleased Shale 1.0.5 or the 1.1.0 branch with the new Tiles 2 release when you do this? I noticed that the new snapshot of Tiles---2.0.3---was not compatible with MyFaces 1.1.4. Maybe it is compatible with MyFaces 1.1.5 or with the 2.x branch. Specifically, MyFaces wanted to load the DefinitionsFactoryExceptions class, but it has moved to a subpackage. It is no longer directly under the org.apache.tiles package but has moved to the org.apache.tiles.definition package. Also, I noticed that the dtds were in transition in the tiles core jar that shipped with the 1.1.0 snapshot that I placed into my working test webapp. They reference: http://struts.apache.org/dtds/tiles-config_2_0.dtd";> and <%@ taglib uri="http://struts.apache.org/tags-tiles"; prefix="tiles" %> These have changed such that struts.apache.org/ is now tiles.apache.org and of course the contents of the corresponding files have changed as well as some of the tag names. For instance tiles:put now appears to be tiles:put-attribute. -=> Gregg <=- Greg Reddin wrote: > > BTW, I'm planning > to upgrade Shale-Tiles to the latest "official" Tiles release once we get > another one out. > > HTH, > Greg > signature.asc Description: OpenPGP digital signature
SUCCESS - Re: Migration: Struts/Tiles to Shale/JSF/Tiles
I appear to have successfully resolved my two page to one page problem.
I no longer need _any_ page, for instance the loadLayout.jsp page, that
contains a tiles:insertDefinition tag. I can simply jump directly to any
tiles definition name. This is how I had Struts/Tiles working before, so
this seems to be the best way to use Tiles with Shale and JSF. I have
posted a test webapp at:
http://www.lansdaletutoring.com/test
The home page at this location allows the user to jump to two different
tiles and, from each of them, back to the home tile and to also download
the test webapp war file.
I changed the index.jsp file to:
My tiles-def.xml file is:
http://struts.apache.org/dtds/tiles-config_2_0.dtd";>
The homeTile.jsp file is:
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %>
<%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %>
<%@ taglib uri="http://myfaces.apache.org/tomahawk"; prefix="t" %>
A Verbatim Method to do The Same Content Tile!
Another paragraph of content.
Another second paragraph of content.
http://www.lansdaletutoring.com/test/files/test.war";>
As far as the org.apache.shale.tiles.TilesViewHandler goes, I don't seem
to need to declare it in faces-config.xml or anywhere else. I suppose it
is being automatically loaded when needed and doesn't need to be
declared. If you want to see the exact error message that does occur
when it is declared in faces-config.xml, just declare it in the exploded
test.war and go to the home page. I believe that it will still fail as
before when this is done. If not, let me know.
-=> Gregg <=-
Greg Reddin wrote:
> On 4/18/07, Gregg Leichtman wrote:
>>
>> I am also using the tiles listener from web.xml as follows:
>>
>>
>>
>> org.apache.tiles.listener.TilesListener
>>
>>
>>
>> instead of the Shale tiles view handler (if this makes a difference) in
>> faces-config.xml:
>>
>>
>>
>> which I could not get to work.
>
>
> [snip]
>
> The Shale/JSF/Tiles scheme that I currently have working seems really
>> clunky.
>>
>> Is there some way that I can reduce the two pages down to one page under
>> Shale/JSF/Tiles?
>
>
> If I understand the TilesViewHandler correctly it is supposed to work
> that
> way. Similar to how TilesRequestProcessor translated a forward
> definition
> into a Tiles invocation. I think TilesViewHandler is supposed to do
> something similar for Tiles 2 in a JSF environment.
>
> What sort of problems did you have with the ViewHandler? BTW, I'm
> planning
> to upgrade Shale-Tiles to the latest "official" Tiles release once we get
> another one out.
>
> HTH,
> Greg
>
signature.asc
Description: OpenPGP digital signature
Migration: Struts/Tiles to Shale/JSF/Tiles
I have created a working webapp that combines Shale 1.1.0 snapshot 20070409 and the tiles jar that came with this snapshot---tiles-core-2.0-r468346-SNAPSHOT.jar along with the supplied MyFaces 1.1.4 jars deployed on either Tomcat 5.5.17 or 6.0.10. The webapp is setup as follows (starting from the webapp root): /index.jsp: /tiles/layouts/loadLayout.jsp: <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %> <%@ taglib uri="http://struts.apache.org/tags-tiles"; prefix="tiles" %> /WEB-INF/tiles-defs.xml: http://struts.apache.org/dtds/tiles-config_2_0.dtd";> /tiles/homeTile.jsp: <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %> <%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %> <%@ taglib uri="http://myfaces.apache.org/tomahawk"; prefix="t" %> A Verbatim Method to do The Same Content Tile! Another paragraph of content. Another second paragraph of content. Another third paragraph of content. /tiles/layouts/siteLayout.jsp <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %> <%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %> <%@ taglib uri="http://struts.apache.org/tags-tiles"; prefix="tiles" %> I am also using the tiles listener from web.xml as follows: org.apache.tiles.listener.TilesListener instead of the Shale tiles view handler (if this makes a difference) in faces-config.xml: which I could not get to work. I have omitted the other tiles, but they just have some simple text or JSF tags in them as dummy filler. This works as I expect it to with everything displayed in proper order, etc. However, this scheme forces me to create two pages for every unique content page I wish to display. For instance, if I want to display a different content page instead of the home tile, I might add a definition in tiles-defs.xml as follows: if I wanted to create new content containing contact information on a contact us page. But with the scheme that I have described above, in order to reference this new definition, I also have to create a new loadContactLayout.jsp page with a definition as follows: <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %> <%@ taglib uri="http://struts.apache.org/tags-tiles"; prefix="tiles" %> Now for the Struts/Tiles portion: In Struts/Tiles I was able to simply declare a global forward and an action as follows: The action's forward leads to a similar pair of tiles definitions in a tiles-def.xml file as follows: with a siteLayout.jsp page: ...snip... ...snip... I can then simply define a URL as http://.../mywebapp/Welcome.do and this causes the tiles context to be instantiated and then causes the appropriate home tile to be rendered on the client. This Struts/Tiles scheme does not need the loadLayout insertDefinition page. The Shale/JSF/Tiles scheme that I currently have working seems really clunky. Is there some way that I can reduce the two pages down to one page under Shale/JSF/Tiles? Also, I would be happy to share this war file or a more elegant one hopefully, if the group feels that this would be useful for others. I had to spend significant time to get this working example up and running and having a working example close to the head of the repository might be useful to others. Would it be worthwhile posting this or a modified war on JIRA for example? -=> Gregg <=- signature.asc Description: OpenPGP digital signature
Re: new to shale tiles
I finally got a tiled page to display after trying a multitude of server and jar versions as well as defining the correct tile contents with appropriate jsf tags and attributes and getting past an IllegalStateException caused by incorrectly having a view tag wrapping the contents of a tile that was being inserted. I learned the hard way that there can only be one---view tag pair per page---and that inserted tiles are, of course, part of a single page (obvious now, but trees vs. forest bit me). At this point however I have not succeeded in accomplishing what you describe below in your index.jsp page where you forward directly to an extended tile. I can't seem to get it to work. I have the following test setup: index.jsp: . . The commented out line above fails. The uncommented line above works. I also tried the commented out line both with and without the leading slash, although the TilesViewHandler javadoc states that the slash is not needed. /tiles/layouts/loadLayout.jsp: . <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %> <%@ taglib uri="http://struts.apache.org/tags-tiles"; prefix="tiles" %> . /tiles/layouts/siteLayout.jsp: . <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %> <%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %> <%@ taglib uri="http://struts.apache.org/tags-tiles"; prefix="tiles" %> . /tiles/htmlHeaderTile.jsp: . <%@ taglib uri="http://java.sun.com/jstl/core"; prefix="c" %> <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %> <%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %> http://localhost:8080/tilestest3";> . /tiles/homeTile.jsp: . Content Tile! A paragraph of content. A second paragraph of content. A third paragraph of content. . tiles-defs.xml: http://struts.apache.org/dtds/tiles-config_2_0.dtd";> . faces-config.xml: . http://java.sun.com/dtd/web-facesconfig_1_1.dtd";> org.apache.shale.tiles.TilesViewHandler . There are no navigation rules defined. I'm just trying to put up a page that doesn't need to go anywhere for this test. As stated above the example webapp works with the one jsp forward but not with the other. When I switch the forwards in index.jsp, I wrapped the contents of siteLayout.jsp, after the taglib defs of course, with an stuff tag pair, but I got no server errors and nothing rendered in the browser---no resulting html source at all. Do you or does anyone else see what am I failing to do or how my approach is significantly different? I'm running on Suse Linux 9.3 with glassfish v2_b20 patched with JSF 1.2_02, shale 1.04 snapshot from 10Oct2006. The jars in WEB-INF/lib are as follows: commons-beanutils-1.7.0.jar commons-chain-1.1.jar commons-digester-1.7.jar commons-logging-1.1.jar jsf-api.jar jsf-impl.jar shale-core-1.0.4-SNAPSHOT.jar shale-spring-1.0.4-SNAPSHOT.jar shale-tiles-1.0.4-SNAPSHOT.jar sp
Tiles failure: java.lang.IllegalStateException
Actually, Antonio's last message caused the light to go on and I saw
that I was not causing the extended tile def to load and consequently
the primary tile def it is derived from to load, so clearly I could not
possibly expect the tiles code to find anything wrapped by either def. I
have since rearranged things to fix this glaring error.
At this point I am getting an illegal state exception within the
siteLayout.jsp compiled code as follows:
[#|2006-10-11T21:51:38.056-0400|INFO|sun-appserver-pe9.1|javax.enterprise.system.tools.deployment|
_ThreadID=11;_ThreadName=Timer-4;|[AutoDeploy] Successfully autodeployed
:
/home/gsl/java/glassfish/glassfish_v2_b20/domains/domain1/autodeploy/tilestest3.war.|#]
[#|2006-10-11T21:51:56.190-0400|WARNING|sun-appserver-pe9.1|javax.enterprise.resource.webcontainer.jsf.taglib|
_ThreadID=12;_ThreadName=httpWorkerThread-8080-1;_RequestID=b9de8883-434e-4aac-b919-73480e7c1a4b;|Can't
leverage base class
java.lang.IllegalStateException
at
com.sun.faces.taglib.jsf_core.ViewTag.getComponentType(ViewTag.java:259)
at
javax.faces.webapp.UIComponentELTag.createComponent(UIComponentELTag.java:219)
at
javax.faces.webapp.UIComponentClassicTagBase.createChild(UIComponentClassicTagBase.java:458)
at
javax.faces.webapp.UIComponentClassicTagBase.findComponent(UIComponentClassicTagBase.java:639)
at
javax.faces.webapp.UIComponentClassicTagBase.doStartTag(UIComponentClassicTagBase.java:1063)
at com.sun.faces.taglib.jsf_core.ViewTag.doStartTag(ViewTag.java:180)
at
org.apache.jsp.tiles.layouts.siteLayout_jsp._jspx_meth_f_view_0(Unknown
Source)
at org.apache.jsp.tiles.layouts.siteLayout_jsp._jspService(Unknown
Source)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
...
There is also a stack trace as follows:
[#|2006-10-11T22:04:25.762-0400|WARNING|sun-appserver-pe9.1|javax.enterprise.resource.webcontainer.jsf.lifecycl
e|_ThreadID=13;_ThreadName=httpWorkerThread-8080-0;_RequestID=e36b4132-d384-4a19-a02d-0ca2563784ed;|executePhas
e(RENDER_RESPONSE 6,[EMAIL PROTECTED]) threw
exception
javax.faces.FacesException: javax.servlet.ServletException: Exception in
'/tiles/layouts/siteLayout.jsp': null
at
com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:418)
at
com.sun.faces.application.ViewHandlerImpl.executePageToBuildView(ViewHandlerImpl.java:410)
at
com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:112)
at
org.apache.shale.tiles.TilesViewHandler.renderView(TilesViewHandler.java:175)
...
Here is how I have changed things and there is now an intermediate
page---loadLayout.jsp---to cause the extended tile
def---/contentPage---and consequently the tile it is derived
from---/mainLayout---to be loaded.
/index.jsp (the web.xml welcome file):
/tiles-defs.xml:
http://struts.apache.org/dtds/tiles-config_2_0.dtd";>
/tiles/layouts/loadLayout.jsp:
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %>
<%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %>
<%@ taglib uri="http://struts.apache.org/tags-tiles"; prefix="tiles" %>
/tiles/htmlHeaderTile.jsp:
<%@ taglib uri="http://java.sun.com/jstl/core"; prefix="c" %>
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %>
<%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %>
/tiles/homeTile.jsp:
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %>
<%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %>
<%@ taglib uri="http://java.sun.com/jstl/core"; prefix="c" %>
Content Tile!
A paragraph of content.
A second paragraph of content.
A third paragraph of content.
/tiles/layouts/siteLayout.jsp:
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %>
<%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %>
<%@ taglib uri="http://struts.apache.org/tags-tiles"; prefix="tiles" %>
http://localhost:8080/tilestest3";>
A, hopefully pertinent, snippet of the siteLayout.jsp generated code
follows:
...
private boolean _jspx_meth_f_view_0(PageContext _jspx_page_context)
throws Throwable {
PageContext pageContext = _jspx_page_context;
JspWriter out = _jspx_page_context.getOut();
// f:view
com.sun.faces.taglib.jsf_core.ViewTag _jspx_th_f_view_0 =
(com.sun.faces.taglib.jsf_core.ViewTag)
_jspx_tagPool_f_view.get(com.sun.faces.taglib.jsf_core.ViewTag.class);
_jspx_th_f_view_0.setPageContext(_jspx_page_context);
_jspx_th_f_view_0.setParent(null);
_jspx_th_f_view_0.setJspId("id6");
int _jspx_eval_f_view_0 = _jspx_th_f_view_0.doStartTag();
<=== gsl
if (_jspx_eval_f_view_0 != javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
if (_jspx_eval_f_view_0 !=
javax.servlet.jsp.tagext.Tag.EVAL_
Re: Tiles Failure in GlassFish: org.apache.tiles.NoSuchDefinitionException
I'm referring to the following post from Mr. Starr: RE: Shale 1.0.3 and Tiles Question - Tag Question <http://www.nabble.com/RE%3A-Shale-1.0.3-and-Tiles-Question---Tag-Question-p6288731.html> Click to flag this post by Dick Starr <http://www.nabble.com/user/UserProfile.jtp?user=4421> Sep 13, 2006; 12:06pm :: Rate this Message: Click to rate as Poor Post <http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#>Click to rate as Below Average Post <http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#>Click to rate as Average Post <http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#>Click to rate as Above Average Post <http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#>Click to rate as Excellent Post <http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#>Click to clear rating <http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#> - Use ratings to moderate (? <http://www.nabble.com/help/Answer.jtp?id=16>) Reply <http://www.nabble.com/forum/Reply.jtp?post=6288731> | Reply to Author <http://www.nabble.com/user/SendEmail.jtp?type=pm&post=6288731> | View Threaded | Link to this Message <http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#a6288731> I installed the 20060911 version and got NullPointerExceptions. It is working now however, with the following fixes: (1) My index.jsp contained where my /tiles/system/SaLogon.jsp now contains (to get it to work I added the type="definition"). (2) In my tiles.xml I have put name="header" ... put name="menuBar" ... put name="body" value=""/> ... (saLogon.jsp is an ... ... ... My tiles inserts work whether or not each insert is bracketed by a subview. Dick Sorry, I'm still confused as to how my original approach is different from Mr. Starr's. As far as I can see, he seems to be inserting tiles in his /tiles/layouts/classicLayout _directly_ from the "puts" for title and body, not from an extended definition wrapped around either the title or body. Is his approach correct because he is inserting from "puts" that are defined within an extended definition? -=> Gregg <=- Antonio Petrelli wrote: > Gregg Leichtman ha scritto: >> I suppose that I could create a different definition like: >> >> >> >> > value="/tiles/headerTile.jsp"/> >> > value="/tiles/rightSideBarTile.jsp"/> >> > value="/tiles/footerTile.jsp"/> >> >> >> >> > value="/tiles/htmlHeaderTile.jsp"/> >> >> >> and then use >> >> > > This is the *right* way! > >> however, I have used the previous method for rendering the "put" >> described _within_ the definition successfully under Tomcat with >> shale-1.0.3. This is also described by Dick Starr at: >> >> >> http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#a6288731 >> >> > > I suppose that Dick describes an already fixed bug, since its NPE > stack trace points to a line where there is no code. > >> Are both of use doing different things? > > Sure! You are trying to forward to a layout page without filling > attributes, you have to forward to a page that contains a > > Dick did the right thing. > >> If so, can you point out what I'm doing that is different or >> something that is now obsolete in shale-1.0.4? >> > > It has nothing to do with Shale, eventually it is a Tiles bug (though > in this case is a bug of yours :-) ). > > Ciao > Antonio > signature.asc Description: OpenPGP digital signature
Re: Tiles Failure in GlassFish: org.apache.tiles.NoSuchDefinitionException
I suppose that I could create a different definition like: and then use however, I have used the previous method for rendering the "put" described _within_ the definition successfully under Tomcat with shale-1.0.3. This is also described by Dick Starr at: http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#a6288731 where he inserts the title and body "puts" successfully. Are both of use doing different things? If so, can you point out what I'm doing that is different or something that is now obsolete in shale-1.0.4? -=> Gregg <=- Antonio Petrelli wrote: > Gregg Leichtman ha scritto: >> /index.jsp: >> >> >> > > The problem is that you are trying to forward to a layout page, > without filling its attributes. > You have to forward to a page that contains: > > (I guess this is what you need) > > where "/welcomePage" is the name of the definition. > > Ciao > Antonio > signature.asc Description: OpenPGP digital signature
Tiles Failure in GlassFish: org.apache.tiles.NoSuchDefinitionException
Ok, let's try this again with proper English. At Greg Reddin's suggestion I have moved to GlassFish v2_b20 in an attempt to get past the need to use the verbatim tag around all non JSF tags within a tile. I have run into a problem that seems to be identical to the fixed problem described in SB-37: tag does not support correctly the "name" attribute. Here are what I believe to be pertinent snippets from various pieces of my webapp. /tiles-defs.xml: http://struts.apache.org/dtds/tiles-config_2_0.dtd";> /web.xml: ... index.jsp ... /index.jsp: /tiles/layouts/siteLayout.jsp <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %> <%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %> <%@ taglib uri="http://struts.apache.org/tags-tiles"; prefix="tiles" %> http://localhost:8080/TilesBug/tiles/layouts/siteLayout.jsp";> /tiles/htmlHeaderTile.jsp <%@ taglib uri="http://java.sun.com/jstl/core"; prefix="c" %> <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %> <%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %> I am using the following libs: commons-beanutils-1.7.0.jar commons-chain-1.1.jar commons-digester-1.7.jar commons-logging-1.1.jar javaee.jar jsf-impl.jar shale-core-1.0.4-SNAPSHOT.jar shale-spring-1.0.4-SNAPSHOT.jar shale-tiles-1.0.4-SNAPSHOT.jar spring-beans-1.2.8.jar spring-context-1.2.8.jar spring-core-1.2.8.jar spring-web-1.2.8.jar tiles-core-2.0-SNAPSHOT-20060922.jar The javaee and jsf-impl jars came directly from the latest j2ee 5 installation. I have successfully gotten the siteLayout.jsp page to render, if the tiles:insert tag is commented out, so I know that JSF is getting that far. I have also used the tiles-defs.xml and web.xml files in my previous Tomcat tests successfully albeit with the verbatim tags peppered all over the place. Does anyone see why I should receive the following exceptions: [#|2006-10-11T05:47:11.145-0400|SEVERE|sun-appserver-pe9.1|javax.enterprise.system.container.web|_ThreadID=12;_ThreadName=httpWorkerThread-8080-1;_RequestID=b9de8883-434e-4aac-b919-73480e7c1a4b;|ApplicationDispatcher[/tilestest3] PWC1231: Servlet.service() for servlet jsp threw exception org.apache.tiles.NoSuchDefinitionException at org.apache.tiles.taglib.InsertTag.processDefinitionName(InsertTag.java:486) at org.apache.tiles.taglib.InsertTag.processName(InsertTag.java:452) ... [#|2006-10-11T05:47:11.222-0400|WARNING|sun-appserver-pe9.1|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=12;_ThreadName=httpWorkerThread-8080-1;_RequestID=b9de8883-434e-4aac-b919-73480e7c1a4b;|executePhase(RENDER_RESPONSE 6,[EMAIL PROTECTED]) threw exception javax.faces.FacesException: javax.servlet.ServletException: Error - Tag Insert : Can't get definition 'null'. Check if this name exists in definitions factory. at com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:418) at com.sun.faces.application.ViewHandlerImpl.executePageToBuildView(ViewHandlerImpl.java:410) at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:112) at org.apache.shale.tiles.TilesViewHandler.renderView(TilesViewHandler.java:175) ... -=> Gregg <=- signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature
Tiles Failure in GlassFish: org.apache.tiles.NoSuchDefinitionException
At Greg Reddins suggestion I have moved to GlassFish v2_b20 in an attempt to get past the need to use the verbatim tag around all non JSF tags within a tile. I have run into a problem that seems to be identical to the fixed problem described in SB-37: tag does not support correctly the "name" attribute. Here are what I believe are pertinent snippets from various pieces of my webapp. /tiles-defs.xml: http://struts.apache.org/dtds/tiles-config_2_0.dtd";> /web.xml: ... index.jsp ... /index.jsp: /tiles/layouts/siteLayout.jsp <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %> <%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %> <%@ taglib uri="http://struts.apache.org/tags-tiles"; prefix="tiles" %> http://localhost:8080/TilesBug/tiles/layouts/siteLayout.jsp";> /tiles/htmlHeaderTile.jsp <%@ taglib uri="http://java.sun.com/jstl/core"; prefix="c" %> <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %> <%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %> I am using the following libs: commons-beanutils-1.7.0.jar commons-chain-1.1.jar commons-digester-1.7.jar commons-logging-1.1.jar javaee.jar jsf-impl.jar shale-core-1.0.4-SNAPSHOT.jar shale-spring-1.0.4-SNAPSHOT.jar shale-tiles-1.0.4-SNAPSHOT.jar spring-beans-1.2.8.jar spring-context-1.2.8.jar spring-core-1.2.8.jar spring-web-1.2.8.jar tiles-core-2.0-SNAPSHOT-20060922.jar The javaee and jsf-impl jars came directly from the latest j2ee 5 installation. I have successfully gotten the siteLayout.jsp page to render, if the tiles:insert tag is commented out, so I know that JSF is getting that far. I have also used the tiles-defs.xml and web.xml files in my previous Tomcat tests successfully albeit with the verbatim tags peppered all over the place. Does anyone see why I should receive the following exceptions: [#|2006-10-11T05:47:11.145-0400|SEVERE|sun-appserver-pe9.1|javax.enterprise.system.container.web|_ThreadID=12;_ThreadName=httpWorkerThread-8080-1;_RequestID=b9de8883-434e-4aac-b919-73480e7c1a4b;|ApplicationDispatcher[/tilestest3] PWC1231: Servlet.service() for servlet jsp threw exception org.apache.tiles.NoSuchDefinitionException at org.apache.tiles.taglib.InsertTag.processDefinitionName(InsertTag.java:486) at org.apache.tiles.taglib.InsertTag.processName(InsertTag.java:452) ... [#|2006-10-11T05:47:11.222-0400|WARNING|sun-appserver-pe9.1|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=12;_ThreadName=httpWorkerThread-8080-1;_RequestID=b9de8883-434e-4aac-b919-73480e7c1a4b;|executePhase(RENDER_RESPONSE 6,[EMAIL PROTECTED]) threw exception javax.faces.FacesException: javax.servlet.ServletException: Error - Tag Insert : Can't get definition 'null'. Check if this name exists in definitions factory. at com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:418) at com.sun.faces.application.ViewHandlerImpl.executePageToBuildView(ViewHandlerImpl.java:410) at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:112) at org.apache.shale.tiles.TilesViewHandler.renderView(TilesViewHandler.java:175) ... -=> Gregg <=- signature.asc Description: OpenPGP digital signature
