[JBoss Seam] - Re: Graceful logout and friendly login ? How to?
by stan.silvert＠jboss.com
"Basel" wrote :
|
| Scenario 1 ? login:
| It is common for the user to login after viewing blogEntry.jsf?id=35. Now, the user would expect blogEntry.jsf?id=35 to be displayed again after the login. For this to work, loginAction.login has to know the view name from which the user clicked on login and any request parameters that were present. However, not knowing this information forces loginAction.login to return ?/home.jsf? so that the user is redirected to the home page.
|
You can easily know the view and the request params using the standard JSF EL variables "view" and "facesContext":
@In
| private UIViewRoot view
|
| @In(value="#{facesContext.externalContext.requestParameterMap}")
| private Map reqParams;
With Seam's new action params feature you also have the option to forego the instance variables and pass these values directly to your action:
>From JSP or Facelets:
<s:commandLink action="#{loginAction.login(view, facesContext.externalContext.requestParameterMap)}" />
In Seam component:
| public String login(UIViewRoot view, Map reqParams) {
| // blah blah
| }
The action params feature is now in the nightly build.
"Basel" wrote :
| Scenario 2 - logout:
| The user is already logged in and is currently viewing blogEntry.jsf?id=35. The user clicks on logout and as a result loginAction.logout returns null so that the current page is redisplayed. At this point the user is redirected to blogEntry.jsf instead of blogEntry.jsf?id=35. As a result, the page action entryAction.setEntry returns a new Entry object that has no properties set.
|
| I tried to access the HttpServletRequest in the second scenario but calling getNames() method on it returned only one parameter which is the conversationId.
|
| I would appreciate any ideas or suggestions that would help in avoiding these two scenarios.
I don't understand. Why do you have to return null from your action? Usually, a logout action sends you to a standard "You've logged out" page.
Also, you should avoid using the HttpServletRequest directly if at all possible. Use the ExternalContext instead.
Stan
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964485#3964485
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964485
19 years, 9 months
[JBoss Portal] - No window states in new portal
by PeterJ
Using the Management Portlet, I created a new portal and added a few portlet instances, including the UserPortletWindow, to the default page. When I display the default page on my new portal, I get the following exception:
2006-08-10 13:19:28,578 ERROR [STDERR] javax.portlet.WindowStateException: Not supported
| 2006-08-10 13:19:28,578 ERROR [STDERR] at org.jboss.portal.portlet.impl.jsr168.PortletURLImpl.setWindowState(PortletURLImpl.java:68)
| 2006-08-10 13:19:28,578 ERROR [STDERR] at org.jboss.portal.portlet.impl.jsr168.taglib.GenerateURLTag.setWindowState(GenerateURLTag.java:242)
| 2006-08-10 13:19:28,578 ERROR [STDERR] at org.jboss.portal.portlet.impl.jsr168.taglib.GenerateURLTag.doEndTag(GenerateURLTag.java:315)
| 2006-08-10 13:19:28,578 ERROR [STDERR] at org.apache.jsp.WEB_002dINF.jsp.user.menu_jsp._jspx_meth_portlet_renderURL_0(menu_jsp.java:185)
| 2006-08-10 13:19:28,578 ERROR [STDERR] at org.apache.jsp.WEB_002dINF.jsp.user.menu_jsp._jspService(menu_jsp.java:80)
| 2006-08-10 13:19:28,578 ERROR [STDERR] at org.jboss.portal.core.servlet.jsp.PortalJsp.service(PortalJsp.java:153)
Looking into the JSP, the error is coming from this line:
<a id="editprofile" href="<portlet:renderURL windowState="maximized"><portlet:param name="op" value="showProfile"/></portlet:renderURL>">
Now, why would "maximized" be an invalid Window state? (By the way, the above errors occur when I am logged in to the portal. If I am not logged in, I get a similar error, but from login.jsp, once again on the portlet:renderURL tag.)
Further research leads me to believe that there are no valid states on any of the portlet instances in the new portal. I say this because the portlet that did work do not have the maximize, minimize, edit or help buttons in the title bar. Is this s bug in 2.4.0.CR3, or is there something I missed in setting up the new portal?
JBoss AS 4.0.4.GA, JBoss Portal 2.4.0.CR3
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964483#3964483
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964483
19 years, 9 months
[JBoss Seam] - Graceful logout and friendly login ? How to?
by Basel
In short, how can I keep track of the GET request parameters and the URL when users login and logout?
For instance, blogEntry.jsf depends on a request parameter called id and a page action entryAction.setEntry. Moreover, login and logout are performed using the two page actions loginAction.login and loginAction.logout.
Scenario 1 ? login:
It is common for the user to login after viewing blogEntry.jsf?id=35. Now, the user would expect blogEntry.jsf?id=35 to be displayed again after the login. For this to work, loginAction.login has to know the view name from which the user clicked on login and any request parameters that were present. However, not knowing this information forces loginAction.login to return ?/home.jsf? so that the user is redirected to the home page.
Scenario 2 - logout:
The user is already logged in and is currently viewing blogEntry.jsf?id=35. The user clicks on logout and as a result loginAction.logout returns null so that the current page is redisplayed. At this point the user is redirected to blogEntry.jsf instead of blogEntry.jsf?id=35. As a result, the page action entryAction.setEntry returns a new Entry object that has no properties set.
I tried to access the HttpServletRequest in the second scenario but calling getNames() method on it returned only one parameter which is the conversationId.
I would appreciate any ideas or suggestions that would help in avoiding these two scenarios.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964476#3964476
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964476
19 years, 9 months
[EJB 3.0] - Re: Is Disciminator used in @OneToMany?
by edvedafi
May be the problem isn't quite what I thought:
Once I added referencedColumnName="" to all of the JoinColumns I was able to eliminate this problem. As well as an @WHERE(clause="type=A") annotation along with the JoinColumns it kindof works.
However now I am noticing that on a OneToMany relationship it is including the discriminator, but on the OneToOne it is not. So if I make them both OneToMany relationships then everything is fine, but If I make Baccount a OneToOne it thorws an exceptions saying that more than one record has been returned. However if I make it a set the size of the set is always one just like it should be.
I have also tried building another Entity that has only One OneToOne with another table that has a discriminator, and I see the same problem.
When I look at the query that Hibernate generates the SQL of the OneToMany it has type=A in the where clause, but on the OneToOne it does not have this as part of the where clause even though I have the @Where annotation.
Why can't I use @Where with a OneToOne relationship?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964473#3964473
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964473
19 years, 9 months
[JBoss jBPM] - Re: Rollback - Business Process
by kukeltje
first, jBPM (the jpdl part) is not bpel. So the analysis is not a (complete) match
1: is covered afaik by jbpm since you get an exception then. You can configure an exceptionhandler and do whatever you want.... Additionally if you want you can even set the token in another node/state. Normally you only get an exception on events like leave-node and 'transition-taken' so jbpm already has some (enough?) support for this.
RollBack methods could be implemented but imo the current support should be sufficient
2: Roling back multiple states etc... hmm... in that if you want the user to be protected, give hime a warning.... 'Are you sure..?" Besides that, jBPM has the option to put the token in any node so a 'goto state' is easy to program, IF the node is in a state (see a Jira issue JBPM-728) Rolling back everything is a different thing. What if letters are already printed and sent out. Those have to be nulled or packages transported or..... These are additional tasks and should therefore be modeled in (my not so humble opinion) Additionally, things can be cascading, rolling back one database update could be possible, but what if that new data is already used in other systems.... hmm..... The implications of these things are major in the systems we work with. I therefore see these things as such exceptions that manual intervention is needed. It would take to much effort to design a system that can handle these very rare happenings
just my ?0,01
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964470#3964470
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964470
19 years, 9 months