[jboss-user] [JBoss Seam] - Re: since today (JBSEAM-954?) I get NPE in setEntityManagerF
!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 that isn't defined acts like a login-required=false, which trying to implement JBSEAM-1009 is bad. One answer would be well, then let's forget about JBSEAM-1009. Not a good answer. Meanwhile I might have a better patch for 1009 working also for overriding restrict ... specific over less specific wildcard (need to test), and am using a nicer pages element attribute name for the on/off flag for this feature weaker-explicit-security=true Any guidance, e.g. whether instead of login-required we now should use require-login to ensure #IMPLIED. Should we replace it, or have both in the code? Doesn't sound good. I hope Seam isn't too old yet to allow change for the better. Sure, one could say have to switch to new DTD anyway to comply for weaker-explicit-security, but the problem are older whatever.page.xml files. Then, we could keep the DTD's ID of the pages.xml and compare all page.xml and throw an exception if on is a different version. That would be dom4j DocumentType method getPublicID? Or getSystemID? I want to get this to work in a way that works for everyone. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4027923#4027923 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4027923 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: since today (JBSEAM-954?) I get NPE in setEntityManagerF
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 : http://www.jboss.com/index.html?module=bbop=viewtopicp=4027951#4027951 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4027951 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: since today (JBSEAM-954?) I get NPE in setEntityManagerF
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 only evaluates that one, ignores less specific wildcards. Why needed, I'll explain if asked. In that context it is unsecure if a missing login-required is interpreted as login-required=false. By conicidence, that's what caused the interaction with 954, the mysterious afterRender beforeRender. The problem with afterRender beforeRender could occur any time there is no login-required but a restrict, but my work on 1009 made it happen sooner on my system. The reasonable workaround I've code today in the mornig and will submit as patch for 1009 hopefully later today is that I now force all DTD public IDs for pages.xml and all whatever.page.xml to be the same, so if someone consciously switches to the new DTD in pages.xml with #IMPLIED then he won't be able to forget an old DTD in any whatever.page.xml. Because that old DTD would cause an undesired login-required=false. I'll be happy to explain it again, but maybe we should have that conversation after I've submitted that 3rd version patch to 1009. I assume you want me to run it for some time here before submitting it :) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4027993#4027993 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4027993 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: since today (JBSEAM-954?) I get NPE in setEntityManagerF
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 functionality on. If it doesn't just work, and fit transparently into the current DTD and current behavior, I won't accept the patch. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4028002#4028002 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4028002 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: since today (JBSEAM-954?) I get NPE in setEntityManagerF
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 is false, per existing DTD, even if it isn't there. Now people who don't want to use the new functionality can keep using the old DTD. The forcing is meant to make sure one site uses the same DTD for all page.xml, because otherwise a single page could have an older DTD, which could be easy to overlook, e.g. copy and paste from an example. The overlooked DTD would make that page less secure, no login-required, a bad oops. The forcing is in a well isolated piece of the patch (yet to submit 3rd version) so it can/could be removed/not incorporated by itself. I think it is figured out relatively nicely, so if it doesn't come across clearly I'll be happy to answer questions. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4028015#4028015 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4028015 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: since today (JBSEAM-954?) I get NPE in setEntityManagerF
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 it is open for discussion what one expects. I think at least it should be optional to get the result one wants if one cares to code it so, and it seems dom4j doesn't let us do that here. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4028022#4028022 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4028022 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: since today (JBSEAM-954?) I get NPE in setEntityManagerF
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 getting the patch right for JBSEAM-1009. Because the DTD says !ATTLIST page login-required (true|false) false we're getting from dom4j element.attribute().getValue() or element.attributeValue() a false even if the attribute isn't there. Any way to tell (the dom4j way) whether attribute login-required has been set explicitely? I've been a JDOM user for years, without DTDs. Wrote XML parser before that, not a dummy. But this automatic fixing up things curtesy of DTD is a bit unnerving. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4027806#4027806 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4027806 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: since today (JBSEAM-954?) I get NPE in setEntityManagerF
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 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: since today (JBSEAM-954?) I get NPE in setEntityManagerF
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 a breakpoint both in PersistenceContexts afterRender() and beforeRender(), then when for the first time trying to log in, resulting in a redirect to a login page, I get the first break in afterRender(), not in beforeRender(): Thread [http-0.0.0.0-8080-1] (Suspended (breakpoint at line 87 in PersistenceContexts)) | PersistenceContexts.afterRender() line: 87 | TransactionalSeamPhaseListener(AbstractSeamPhaseListener).afterRender(FacesContext) line: 233 | TransactionalSeamPhaseListener(SeamPhaseListener).afterPhase(PhaseEvent) line: 116 | PhaseListenerManager.informPhaseListenersAfter(PhaseId) line: 89 | LifecycleImpl.render(FacesContext) line: 391 | FacesServlet.service(ServletRequest, ServletResponse) line: 138 | ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 252 | ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 173 | SeamFilter$FilterChainImpl.doFilter(ServletRequest, ServletResponse) line: 63 | RedirectFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 45 | SeamFilter$FilterChainImpl.doFilter(ServletRequest, ServletResponse) line: 49 | ExceptionFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 57 | SeamFilter$FilterChainImpl.doFilter(ServletRequest, ServletResponse) line: 49 | MultipartFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 79 | SeamFilter$FilterChainImpl.doFilter(ServletRequest, ServletResponse) line: 49 | SeamFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 84 | ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 202 | ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 173 | TidyXMLFilter(BaseXMLFilter).doXmlFilter(FilterChain, HttpServletRequest, HttpServletResponse) line: 67 | Filter(BaseFilter).doFilter(ServletRequest, ServletResponse, FilterChain) line: 223 | ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 202 | ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 173 | ReplyHeaderFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 96 | ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 202 | ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 173 | StandardWrapperValve.invoke(Request, Response) line: 213 | StandardContextValve.invoke(Request, Response) line: 178 | SecurityAssociationValve.invoke(Request, Response) line: 175 | NonLoginAuthenticator(AuthenticatorBase).invoke(Request, Response) line: 432 | JaccContextValve.invoke(Request, Response) line: 74 | StandardHostValve.invoke(Request, Response) line: 126 | ErrorReportValve.invoke(Request, Response) line: 105 | CachedConnectionValve.invoke(Request, Response) line: 156 | StandardEngineValve.invoke(Request, Response) line: 107 | CoyoteAdapter.service(Request, Response) line: 148 | Http11Processor.process(InputStream, OutputStream) line: 869 | Http11Protocol$JmxHttp11ConnectionHandler(Http11BaseProtocol$Http11ConnectionHandler).processConnection(TcpConnection, Object[]) line: 664 | PoolTcpEndpoint.processSocket(Socket, TcpConnection, Object[]) line: 527 | MasterSlaveWorkerThread.run() line: 112 | ThreadWithAttributes(Thread).run() line: 595 The FacesContext on the stack in its external context shows we're still at the original page, the one that requires the login. My best guess is that maybe because in Pages method enterPage() if there is a redirectToLoginView() then the page.enter() isn't called. Whether there is a significant difference in that behavior with or without JBSEAM-1009 I can't grasp for sure, but it seems even without 1009 there will be a call to redirectToLoginView() without calling page.enter(). So the answer would be you can get there with a redirectToLoginView(). Does that answer the question? If still needed, I can offer my Eclipse to debug with simple remote login to a URL in the browser, Windows and Mac. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4027343#4027343 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4027343 ___ jboss-user mailing list
[jboss-user] [JBoss Seam] - Re: since today (JBSEAM-954?) I get NPE in setEntityManagerF
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 the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4027353 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: since today (JBSEAM-954?) I get NPE in setEntityManagerF
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 : http://www.jboss.com/index.html?module=bbop=viewtopicp=4026449#4026449 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4026449 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: since today (JBSEAM-954?) I get NPE in setEntityManagerF
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 redirect to another page. Not sure about details though. And it happens during a login redirection that I've been mentioning I'm working on. Not sure though whether that makes/made any difference. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4026457#4026457 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4026457 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: since today (JBSEAM-954?) I get NPE in setEntityManagerF
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 more stable in case someone two years from now changes the default flush mode or even just tries understanding the logic. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4026539#4026539 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4026539 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
