!ATTLIST page login-required (true|false) #IMPLIED instead of false fixes
the problem on my machine.
The bigger problem though would be people who don't change the DTD e.g. from
1.2 to either 1.2.1 or 1.3 and still get the false instead of recognizing it
isn't defined. So a login-required
You've totally lost me now.
That change to the DTD is not a breaking change and, following the policy we
have used for Hibernate for years, non-breaking DTD changes do not require an
increment of the version number.
View the original post :
JBSEAM-1009 is about (if switched on) explicitly setting login-required (and
restrict) per page or per wildcard in a way that allows a specific page to be
less restricted than a * site wide wildcard. For each (login-required and
restrict) it picks the most specific page where it is defined and
Sorry, I won't be accepting any patch that is implemented as you just described.
A missing login-required should be interpreted as null, and delegate to the
more general widcard.
I certainly won't be forcing any kind of DTD update on users, or (worse)
accepting any switch that turns this
Exactly, I agree with
anonymous wrote : A missing login-required should be interpreted as null, and
delegate to the more general widcard.
And that's where dom4j and the existing DTD are messing with us. Because there
isn't a way to tell the login-required isn't there. Dom4j insists on saying
It also works fine (I think to remember) without DTD listed in any page.xml,
because then dom4j doesn't say it is false when in fact it isn't there.
One could say that's a bad library, that returns different results for an
attribute value whether the DTD is mentioned in the XML or not. Though
Not 100% confirmed, but I think I got a reproducible case:
Don't have a login-required for a page, but for the page have a s:hasRole or
s:hasPermission that consequentially throws a different exception than what you
probably have been expecting.
Meanwhile though ... I'm having a heck of a time
So change the DTD to use IMPLIED instead of false.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4027811#4027811
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4027811
___
Trying to answer Gavin's question how I get this.
To be clear, the NPE is gone with actualFlushMode not being null any more.
For completeness of record let's mention I'm now running the 2nd patch of
JBSEAM-1009 on a build we did from a CVS pull on Friday.
When starting up the server and having
No it does not answer the question. No way should JSF ever call afterPhase()
without a prior beforePhase(). And there is no other exit point (apart from
exceptions) from beforeRender().
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4027353#4027353
Reply to
I would love to know how you managed to produce this. I dont understand how
PersistenceContexts.afterRender() could get called w/o an earlier call to
beforeRender().
Perhaps if an exception occurred?
View the original post :
Importantly to my well being in put in that
private FlushModeType actualFlushMode = FlushModeType.AUTO;
and now I'm running without crashes.
When I'm out of trouble for the afternoon I'll look again.
One hint how I got there might be: Page action returns outcome, navigation
rule makes it
I know I've suggested the exact wording, but my consciousness will bug me if I
don't mention the following. If the fix instead of
private FlushModeType actualFlushMode = FlushModeType.AUTO;
would write to the same effect
private FlushModeType actualFlushMode = flushMode;
then it would be
13 matches
Mail list logo
