You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Wolfgang Gehner <ne...@infonoia.com> on 2005/02/04 09:51:25 UTC
TilesPlugin RequestProcessor compatibility check issue
Hi Guys,
I am testing Struts 1.3 with Tiles.
I see
http://svn.apache.org/viewcvs.cgi/struts/core/trunk/src/share/org/apache/struts/tiles/TilesPlugin.java?rev=57589&view=markup
and think that the test(s)
tilesProcessorClass.isAssignableFrom(configProcessorClass)
should be inverted, as in:
configProcessorClass.isAssignableFrom(tilesProcessorClass)
IsAssignable is the inversion of "extends", and I guess the test should be
if tilesProcessorClass extends configProcessorClass, i.e.
Best regards,
Wolfgang Gehner
Co-author "Struts Best Practices"
http://www.amazon.de/exec/obidos/ASIN/3898642844
http://www.amazon.fr/exec/obidos/ASIN/2100486357
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: TilesPlugin RequestProcessor compatibility check issue
Posted by Joe Germuska <Jo...@Germuska.com>.
>But, in short, you're right.
Whoops; no, you're not, although there was an error along these lines
in the current code.
Here's what is there right now:
[1] // Check to see if request processor uses struts-chain. If so,
// no need to replace the request processor.
if
(configProcessorClass.isAssignableFrom(ComposableRequestProcessor.class))
{
return;
}
[2] // Check if it is the default request processor or Tiles one.
// If true, replace by Tiles' one.
if (configProcessorClassname.equals(RequestProcessor.class.getName())
|| configProcessorClassname.endsWith(tilesProcessorClassname)) {
ctrlConfig.setProcessorClass(tilesProcessorClassname);
return;
}
[3] // Check if specified request processor is compatible with Tiles.
Class tilesProcessorClass = TilesRequestProcessor.class;
if (!tilesProcessorClass.isAssignableFrom(configProcessorClass)) {
// Not compatible
String msg =
"TilesPlugin : Specified RequestProcessor not
compatible with TilesRequestProcessor";
if (log.isFatalEnabled()) {
log.fatal(msg);
}
throw new ServletException(msg);
}
The first test, [1] is an error of the sort you observed. It should
be testing to make sure that the specified class is a subclass of
ComposableRequestProcessor.class and not the other way around.
The second test, [2], seems dubious. Particularly testing against
class names. If it weren't for a concern with breaking Struts
installations which use Tiles and don't specify the
TilesRequestProcessor, i'd remove this. However, now that in Struts
1.3 the default processor is the ComposableRequestProcessor, this
test will never be evaluated unless someone has explicitly set their
processor class, and in that case, they should explicitly set it
*correctly* ;-) Still, i'll leave it in there temporarily in case
I'm missing something.
The third test, [3], is correct. Assure that the current
configProcessorClass extends TilesRequestProcessor. No need to
change it.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: TilesPlugin RequestProcessor compatibility check issue
Posted by Joe Germuska <Jo...@Germuska.com>.
I think you're using the wrong version of the Tiles Plugin. For
Struts 1.3, Tiles has been pulled out to
http://svn.apache.org/repos/asf/struts/tiles
and the head version of the plugin is at
http://svn.apache.org/repos/asf/struts/tiles/trunk/src/java/org/apache/struts/tiles/TilesPlugin.java
As far as I'm concerned, that compatibility check should be
completely removed. I don't like the TilesPlugIn changing things
like that, and I think people could learn quickly enough that they
have to specify a different RequestProcessor if they want to use
Tiles.
Actually, on my way into work this morning, the whole idea of making
Tiles a standalone project really clicked for me; I'd love to see
Struts become completely ignorant of Tiles, simply having a
TilesServlet handle request dispatches for a standard mapping like
"*.tiles". My understanding is that this, or something like it, is
in the works, but I don't think the principal instigators have found
much time yet to move forward on it. So it probably wouldn't come to
pass until Struts 1.4 or later.
But, in short, you're right.
"Determines if the class or interface represented by this Class
object is either the same as, or is a superclass or superinterface
of, the class or interface represented by the specified Class
parameter. It returns true if so; otherwise it returns false. If this
Class object represents a primitive type, this method returns true
if the specified Class parameter is exactly this Class object;
otherwise it returns false."
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#isAssignableFrom(java.lang.Class)
Joe
At 9:51 AM +0100 2/4/05, Wolfgang Gehner wrote:
>Hi Guys,
>
>I am testing Struts 1.3 with Tiles.
>
>I see
>
>http://svn.apache.org/viewcvs.cgi/struts/core/trunk/src/share/org/apache/struts/tiles/TilesPlugin.java?rev=57589&view=markup
>
>and think that the test(s)
>
>tilesProcessorClass.isAssignableFrom(configProcessorClass)
>
>should be inverted, as in:
>
>configProcessorClass.isAssignableFrom(tilesProcessorClass)
>
>IsAssignable is the inversion of "extends", and I guess the test should be
>if tilesProcessorClass extends configProcessorClass, i.e.
>
>
>Best regards,
>
>Wolfgang Gehner
>Co-author "Struts Best Practices"
>http://www.amazon.de/exec/obidos/ASIN/3898642844
>http://www.amazon.fr/exec/obidos/ASIN/2100486357
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org