Hi Jens,
> Exception in thread "Timer-0" java.lang.NullPointerException
I'm sorry I cannot say anything about your NullPointerExceptions. I have never
had this problem, so I've got no idea where to look at.
> I'm also facing Tomcats Permanent Generation constantly growing with each
> re-deploy. Just to mention, don't know, if this is related.
I do not think it's Tapestry related. I've been facing this with Hibernate
using the bytecode provider CGLIB. Configure your Hibernate to use javassist
instead or upgrade to the newest version of Hibernate, which uses javassist by
default.
> String path = request.getPath();
> String[] roles = sitemap.getRoles(path);
>
> logger.debug(roles == null ? "no roles attached" : "roles: "
> + roles.toString());
>
> //no roles defined means access for all
> if (roles == null) { return false; }
This could be the source of errors. I presume in your Sitemap you use a Map of
paths mapping to the String-Arrays with the roles. So whenever the path (for
whatever reason) looks only slightly different from what you expect, you won't
find a match. Resulting in roles to be null and access to be granted (Mind you
return false here before checking the user data!). You should consider
reimplementing that logic to "if roles == null, forbid access". I'd at least
put in a log statement to log the path variable to see, if that causes the
errors.
The code for checking the user data seems ok to me. I cannot spot any obvious
flaws.
> if (!isAuthorized) {
> PageRenderRequestParameters params =
> new PageRenderRequestParameters(
> LOGINPAGE,
> new EmptyEventContext());
> this.renderer.handle(params);
> return true;
> }
I am not very familiar with this approach to redirect to the login page. So I
do not know whether this might cause the error you are facing. Although i
suggest a different solution as it at least makes your code in the dispatch
method a bit cleaner. Insetad of the renderer use the LinksourceService and
thre responses "sendRedirect"-method. See the following implementation of
Dispatcher:
public final class AuthorizationDispatcher implements Dispatcher {
private final Link indexPageLink;
public AuthorizationDispatcher(
final PageRenderLinkSource pageRenderLinkSource) {
/*
* We only need pageRenderLinkSource for creating a fixed Link
to index page
* without any parameters or context. We directly create the
link and
* store it in a final field.
*/
this.indexPageLink = pageRenderLinkSource
.createPageRenderLink(Index.class);
}
@Override
public final boolean dispatch(final Request request, final Response
response)
throws IOException {
/*
* This test checks whether the app's index page is requested.
If so,
* won't dispatch.
*/
if (request.getPath().equals("/index") ||
request.getPath().equals("/")) {
return false;
}
/*
* If sth. else than app's index page is requested will allways
redirect
* to index. I.e. an authorization check that always fails,
very secure ;-))
*/
response.sendRedirect(this.indexPageLink);
return true;
}
}
And in AppModule add the two following methods:
public static final Dispatcher buildAuthorizationDispatcher(
final PageRenderLinkSource pageRenderLinkSource) {
return new AuthorizationDispatcher(pageRenderLinkSource);
}
public static final void contributeMasterDispatcher(
final OrderedConfiguration<Dispatcher> dispatchers,
@InjectService("AuthorizationDispatcher") final
Dispatcher authorizationDispatcher) {
dispatchers.add("AuthorizationDispatcher",
authorizationDispatcher,
"before:ComponentEvent", "before:PageRenderer");
}
Cheers nillehammer
----- original Nachricht --------
Betreff: RE: RE: contribute mystery
Gesendet: Di, 16. Nov 2010
Von: Jens Reufsteck<jens.reufst...@staufenbiel.de>
> Hi nillehammer
>
> with further testing on Tomcat I'm finding the following in catalina.out:
>
> Exception in thread "Timer-0" java.lang.NullPointerException
> at
> com.mchange.v2.log.log4j.Log4jMLog$Log4jMLogger.isLoggable(Log4jMLog.java:25
>
> 5)
> at
> com.mchange.v2.resourcepool.BasicResourcePool$CullTask.run(BasicResourcePool
>
> .java:1934)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
>
> I'm also facing Tomcats Permanent Generation constantly growing with each
> re-deploy. Just to mention, don't know, if this is related.
>
>
> This is the dispatch-method:
>
> public boolean dispatch(Request request, Response response) throws
> IOException {
> String path = request.getPath();
> String[] roles = sitemap.getRoles(path);
>
> logger.debug(roles == null ? "no roles attached" : "roles: "
> + roles.toString());
>
> //no roles defined means access for all
> if (roles == null) { return false; }
>
> User user = auth.getUser();
>
> logger.debug(user == null ? "no user attached" : "user " +
> user.getName() + "; groups: " + user.getGroups().toString());
>
> boolean isAuthorized = false;
> for (String roleName : roles) {
> if (user != null && user.isInGroup(roleName)) {
> isAuthorized = true;
> }
> }
>
> logger.debug("isAuthorized: " + isAuthorized);
>
> //if Authorization fails we hand over to the next renderer,
> i.e. the PageRender
> if (!isAuthorized) {
> PageRenderRequestParameters params =
> new PageRenderRequestParameters(
> LOGINPAGE,
> new EmptyEventContext());
> this.renderer.handle(params);
> return true;
> }
>
> return false;
> }
>
>
> I'll post, if I can get hold of anything else.
>
> Many thanks
> Jens
>
> --
> Jens Reufsteck
> Marketing & Online Director
>
> Staufenbiel Institut GmbH
> Events & Recruiting Solutions
>
> Wildunger Straße 6, 60487 Frankfurt am Main
> www.staufenbiel.de www.mba-master.de www.absolventenkongress.de
>
> Tel.: +49 (0)69 25537-140
> Fax: +49 (0)69 25537-2140
>
> Geschäftsführer: Judith Oppitz, Birgit Giesen, Graham Storey, Martin
> Halliday
> Amtsgericht Köln HRB 9301
>
> Internet communications are not secure and therefore Staufenbiel Institut
> GmbH does not accept legal responsibility
> for the contents of this message. Any views or opinions presented are
> solely
> those of the author and do not
> necessarily represent those of Staufenbiel Institut GmbH unless otherwise
> specifically stated.
> > -----Original Message-----
> > From: nille hammer [mailto:tapestry.nilleham...@winfonet.eu]
> > Sent: Monday, November 15, 2010 8:31 PM
> > To: Tapestry users
> > Subject: Re: RE: contribute mystery
> >
> > Hi Jens,
> >
> > just to make sure:
> > > maybe I wasn't quite clear: on some startups my dispatcher is used (and
> than
> > > is always used, which is what I want). On other startups (i.e.
> restarting
> > > jetty/tomcat) the dispatcher is never used. Though log show, that it is
> > > instantiated. But then it feels, as if it wasn't included in the
> dispatchers
> > > chain of commands.
> >
> > As far as I understand your mails, your "AuthorizationDispatcher" is
> certainly instanciated
> > and contributed on every startup, but in about 50% of the times it feels
> like it is not doing
> > its work.
> >
> > If so, could it be an error in the implementation of your "dispatch()"
> method? If you parse
> > Strings in the request, maybe in the 50% not working, the Strings are
> presented a bit
> > differently than in the other cases, urlencoded characters. Or it
> sometimes fails to load its
> > dependencies (maybe SiteMap) or loads a mock implementation of that.
> >
> > To clarify could you post your dispatch()-method?
> >
> > Cheers nillehammer.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--- original Nachricht Ende ----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
