After battling with getting trunk deployed to Tomcat 5.5.15, the blank
page error problem doesn't affect it.  I guess it's likely that it's a
Resin bug (it happens on both 2.1.17, and 3.0.17 - when the
CompressionFilter is enabled and the downstream filter, or servlet sets
a response error, or a status code).

For people who are trying to develop on Tomcat 5.5.15 along with trunk
(and roller is not showing up - just getting a blank page, or are
getting JSTL errors) you have to do the following 

Tips for getting Roller Trunk working on Tomcat 5.5


1) Symptom: 

org.apache.jasper.JasperException: Unable to read TLD "META-INF/c.tld"
from JAR file
"file:/C:/build/Blogs/trunk/build/roller/WEB-INF/lib/standard.jar":
org.apache.jasper.JasperException: Failed to load or instantiate
TagLibraryValidator class: org.apache.taglibs.standard.tlv.JstlCoreTLV
        
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHand
ler.java:50)

Fix:

Make sure the JSTL 1.0.3 tld's (you can copy them from
trunk/tools/standard-1.0.3/tld/*) are in your WEB-INF/tlds folder, then
make sure you register the taglibs in your web.xml

  <taglib>
    <taglib-uri>http://java.sun.com/jstl/fmt</taglib-uri>
    <taglib-location>/WEB-INF/tlds/fmt.tld</taglib-location>
  </taglib>

  <taglib>
    <taglib-uri>http://java.sun.com/jstl/fmt-rt</taglib-uri>
    <taglib-location>/WEB-INF/tlds/fmt-rt.tld</taglib-location>
  </taglib>

  <taglib>
    <taglib-uri>http://java.sun.com/jstl/core</taglib-uri>
    <taglib-location>/WEB-INF/tlds/c.tld</taglib-location>
  </taglib>

  <taglib>
    <taglib-uri>http://java.sun.com/jstl/core-rt</taglib-uri>
    <taglib-location>/WEB-INF/tlds/c-rt.tld</taglib-location>
  </taglib>

  <taglib>
    <taglib-uri>http://java.sun.com/jstl/sql</taglib-uri>
    <taglib-location>/WEB-INF/tlds/sql.tld</taglib-location>
  </taglib>

  <taglib>
    <taglib-uri>http://java.sun.com/jstl/sql-rt</taglib-uri>
    <taglib-location>/WEB-INF/tlds/sql-rt.tld</taglib-location>
  </taglib>

  <taglib>
    <taglib-uri>http://java.sun.com/jstl/x</taglib-uri>
    <taglib-location>/WEB-INF/tlds/x.tld</taglib-location>
  </taglib>

  <taglib>
    <taglib-uri>http://java.sun.com/jstl/x-rt</taglib-uri>
    <taglib-location>/WEB-INF/tlds/x-rt.tld</taglib-location>
  </taglib>


2) Symptom: 

java.lang.ClassCastException
        
org.apache.jasper.compiler.TagLibraryInfoImpl.createValidator(TagLibrary
InfoImpl.java:651)

or

org.apache.jasper.JasperException: Failed to load or instantiate
TagLibraryValidator class: org.apache.taglibs.standard.tlv.JstlCoreTLV

Fix

Remove WEB-INF/lib/jsp-api.jar (it conflicts with the one that comes w/
Tomcat 5.5).

George Daswani

-----Original Message-----
From: Matt Raible [mailto:[EMAIL PROTECTED] 
Sent: Friday, March 03, 2006 9:43 AM
To: roller-dev@incubator.apache.org
Subject: Re: bug? RollerAtomHandler permission check

On 3/3/06, George Daswani <[EMAIL PROTECTED]> wrote:
> Update.  I implemented the Read Security Check as a servlet filter
> (bound to /page/*) and ran into what seems to be a bug with the
> Compression Filter.  When it's enabled, any servlet filter downstream
> that sets the http response code (or servlet) breaks (just returns a
> blank page, instead of the proper error code / jsp).
>
> Basically, doing an
> HttpServletReponse.sendError(HttpServletResponse.SC_FORBIDDEN) returns
a
> blank page (either from a servlet filter, or a velocity servlet).
> Removed the Compression Filter mapping on /page/*, and it works just
> fine.
>
> Servlet Engine = Resin 2.1.17
> Trunk Subversion copy (pulled about a week ago)

Can you try it on Tomcat and see if you experience the same issue?

Matt

>
> George Daswani
>
> -----Original Message-----
> From: George Daswani [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 02, 2006 8:55 AM
> To: roller-dev@incubator.apache.org
> Subject: RE: bug? RollerAtomHandler permission check
>
> Hello,
>
>         In regards to the read access permission, I basically added a
> new WebsiteData Boolean attribute called "restricted" - the admins can
> then toggle said bit (similar to the active flag) on/off.
>
> I extended the PermissionsData so it became
>
> public static short READERS = 0x01; // 0001
> public static short LIMITED = 0x03; // 0011
> public static short AUTHOR  = 0x07; // 0111
> public static short ADMIN   = 0x0F; // 1111
>
> I'm currently modifying the Page Servlet and the various other
servlets
> to do the following simple check
>
> if ( WebsiteData.isRestricted() ){
>         // check if user has READ permission to said website
>         If ( user == null  ){
>                 if ( WebSiteData.hasUserPermissions(user,
> PermissionsData.READERS){
>                    // display the page
>                 } else {
>                    // set response as forbidden
>                 }
>         } else {
>
>                 // not logged in, we need to store this page link for
> use by
>                 // ACEGI - so that after the scurity check, we get
this
> page
>
>                 // session.setAttribute(
>
AbstractProcessingFilter.ACEGI_SECURITY_TARGET_URL_KEY,WHATEVER_THE_CURR
> ENT_URL_IS)
>                 // redirect  to  "/j_security_check"
>
>         }
> } else {
>         // not restricted, just do what we normally do
> }
>
> The following pages will then be modified
>
> "tabbedmenu.website.members"
>
> The admin will have the option of setting a user to one of the
following
> permissions
>
> someuser -> { "Admin", "Author", "Limited", "Reader" , "Remove" }
>
> on the right actions panel, a new action will be available called
> something like "Add Member Permission" which works similarly to the
> "Invite New Member" except it doesn't invite (it adds directly).
>
> IMHO, the above is the least invasive way to add read access
permissions
> to a blog site.  I'm pretty sure a couple of people will want better
> permissions (ie. Users -> groups -> permissions -> blogs)
>
> Another approach to doing this might be to create another ACEGI filter
> that unders the Roller request/context, can grok the website read
> restriction attribute, permission requirements.  We should be able to
> insert such a filter in the security.xml (which in turn won't require
> programmatic security checking in the various servlets).
>
> George Daswani
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 02, 2006 5:44 AM
> To: roller-dev@incubator.apache.org
> Subject: Re: bug? RollerAtomHandler permission check
>
>
>
> On Feb 28, 2006, at 6:46 PM, George Daswani wrote:
>
> > Speaking of Permissions, I'm currently modifying roller so that
> > certain
> > blog websites have read access restrictions (private, accessible
> > only by
> > users with read permissions or above via roller users).  Was
thinking
> > about the doing following, and would such a thing be useful to other
> > people?
> >
> > Basically modifying the current permission set from
> >
> >     public static short LIMITED = 0x00; // 0000
> >     public static short AUTHOR  = 0x01; // 0011
> >     public static short ADMIN   = 0x03; // 0011
> >
> > to
> >
> >     public static short READ    = 0x00; // 0000
> >     public static short LIMITED = 0x01; // 0001
> >     public static short AUTHOR  = 0x03; // 0011
> >     public static short ADMIN   = 0x07; // 0111
> >
> > then modify the various templates to support it?  Would such a
> > patch be
> > useful to other people?
>
> As I've said before, I think "private" is a very important feature
> for business and personal bloggers alike, so I've love to see this
> patch. Your patch will probably have a higher chance of acceptance if
> you share/discuss your design here on the list.
>
> - Dave
>
>
>
>
>

Reply via email to