[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2178) Differ timed out session from new session
by Sheng Huang (JIRA)
Differ timed out session from new session
-----------------------------------------
Key: JBSEAM-2178
URL: http://jira.jboss.com/jira/browse/JBSEAM-2178
Project: JBoss Seam
Issue Type: Feature Request
Components: Core
Affects Versions: 2.0.0.BETA1
Environment: Windows XP SP2
Reporter: Sheng Huang
It will be nice to differ session timeout from newly created session.
For example, if I bookmark a page requiring login, it is desired that the application redirects me to the login page and the message "Please log in first" is fine. However, if I have been inactive for a while thus my session times out, it is preferred to display a message like "Your session times out. Please login again".
I checked SeamListener and LifeCycle classes, but I cannot find a way to link timed out session with the subsequently created new session. Is this possible that Seam can raise an event or set a flag when timeout then link to the new session after user is redirected to the login page again?
I greatly appreciate if you can look at the possibility or let me know if there is a workaround. Thank you very much for your help.
Best regards,
Sheng
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2146) New instance of stateful session bean is created twice in the same session
by Igor Laberov (JIRA)
New instance of stateful session bean is created twice in the same session
--------------------------------------------------------------------------
Key: JBSEAM-2146
URL: http://jira.jboss.com/jira/browse/JBSEAM-2146
Project: JBoss Seam
Issue Type: Bug
Components: EJB3, JSF
Affects Versions: 2.0.0.BETA1
Environment: Win XP, JBoss 4.2.1, desktop computer, !! IE 6.0 !!
Reporter: Igor Laberov
The page consists of dataTable and combo box for data paging.
During request, in update model phase, some session bean variable is updated in existing session bean instance. However, during invoke application phase, new instance of stateful session bean is created. No exception were logged and 'destroy' method of existing instance wasn't called.
It happens only in IE6. In IE7 and FF2.0 the behavior is OK.
Sniffing of HTTP request shows the difference in POST parameters:
IE6 -
main_form=main_form&
main_form%3Adata%3A2%3Adel_=&
main_form%3AselectedRemoveIndex=745&
main_form%3AdeletePanelOpenedState=&
javax.faces.ViewState=_id18
IE7 and FF -
main_form=main_form&
main_form%3Adata%3A0%3Adel_=&
main_form%3AselectedRemoveIndex=589&
main_form%3Aj_id97=11&
main_form%3AdeletePanelOpenedState=&
javax.faces.ViewState=_id9
while, as you can see it differs by one paramer - 'j_id97', which is id of combo box (that wasn't changed by user).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1204) java.lang.StringIndexOutOfBoundsException: String index out of range: -1
by Petr Ferschmann (JIRA)
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
------------------------------------------------------------------------
Key: JBSEAM-1204
URL: http://jira.jboss.com/jira/browse/JBSEAM-1204
Project: JBoss Seam
Issue Type: Bug
Components: Framework
Affects Versions: 1.2.1.GA
Environment: I am using Seam for other serlvets too (SeamFilter).
Reporter: Petr Ferschmann
Problem is that MockViewHandler expects that there is always . in URL (but in my case it is not).
String index out of range: -1
RequestURI=/pes/userAccount/create/
Caused by:
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1762)
at java.lang.String.substring(String.java:1735)
at org.jboss.seam.mock.MockViewHandler.getActionURL(MockViewHandler.java:41)
at org.jboss.seam.core.Manager.redirect(Manager.java:1054)
at org.jboss.seam.core.Redirect.execute(Redirect.java:137)
at org.jboss.seam.exceptions.DebugPageHandler.handle(DebugPageHandler.java:29)
at org.jboss.seam.core.Exceptions.handle(Exceptions.java:79)
at org.jboss.seam.web.ExceptionFilter.endWebRequestAfterException(ExceptionFilter.java:91)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:73)
at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:79)
at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
at org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:268)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126)
at cz.softeu.rewriter.RewriterFilter.doFilter(RewriterFilter.java:173)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:751)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1075) Documentation enhancement for injecting Logger (make clear when static is required)
by Arjan van Bentem (JIRA)
Documentation enhancement for injecting Logger (make clear when static is required)
-----------------------------------------------------------------------------------
Key: JBSEAM-1075
URL: http://jira.jboss.com/jira/browse/JBSEAM-1075
Project: JBoss Seam
Issue Type: Feature Request
Components: Documentation
Affects Versions: 1.2.0.GA
Environment: All
Reporter: Arjan van Bentem
Priority: Optional
The documentation of @Logger in "3.6 Logging" states at http://fisheye.jboss.com/browse/JBoss/jboss-seam/doc/reference/en/modules...
It doesn't matter if you declare the log variable static or not—it will work either way.
I think this should be enhanced to read, for example:
It doesn't matter if you declare the log variable static or not—it will work either way,
except for entity beans which needs the logger to be static.
...maybe followed by an example:
@Entity
@Name("member")
@Table(uniqueConstraints = @UniqueConstraint(columnNames = "membername"))
public class Member implements Serializable
{
@Logger private static Log log;
:
public void setMemberName(String memberName)
{
log.info("setting memberName");
this.memberName = memberName;
}
:
}
At least, that's what I've found; when not declaring it static it will not get injected or is lost (I'm not sure which), and thus would yield a NullPointerException upon usage.
Likewise, "22.2. Annotations for bijection" at http://fisheye.jboss.com/browse/JBoss/jboss-seam/doc/reference/en/modules... now states
Specifies that a component field is to be injected with an instance of org.jboss.seam.log.Log.
...but maybe this could be extended to read:
Specifies that a component field is to be injected with an instance of org.jboss.seam.log.Log.
Remember that for entity beans the actual variable needs to be declared static.
Cheers,
Arjan.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1383) Add conversation propogation="clone" ability
by Michael Youngstrom (JIRA)
Add conversation propogation="clone" ability
--------------------------------------------
Key: JBSEAM-1383
URL: http://jira.jboss.com/jira/browse/JBSEAM-1383
Project: JBoss Seam
Issue Type: Feature Request
Components: Core
Affects Versions: 1.2.1.GA
Reporter: Michael Youngstrom
I think the ability to clone a conversation would be useful.
Currently if I have an s:link and I do an "open in new window" on that link I now have 2 windows linked to the same conversation which may produce undesirable side effects to the user.
So the idea is with s:link or other "GET" types of requests where the user might be inclined to do an "Open in new Window" type of operation we add the ability to clone the conversation when executed. If applied to an s:link the conversation would always be cloned when that link is executed. That way if the user did do an "Open in new window" each window would have 2 independent conversations.
This would obviously have the side effect of an orphaned conversation if the user didn't do an "open in new window or tab" so the user would have to weigh the cost of creating orphaned conversations against maintaining the Conversation per window type of semantics this feature would provide.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1745) SpringTransaction fails with HibernateJpaDialect and FlushMode.MANUAL
by Darryl Smith (JIRA)
SpringTransaction fails with HibernateJpaDialect and FlushMode.MANUAL
----------------------------------------------------------------------
Key: JBSEAM-1745
URL: http://jira.jboss.com/jira/browse/JBSEAM-1745
Project: JBoss Seam
Issue Type: Bug
Components: Spring
Reporter: Darryl Smith
When using flushMode = MANUAL with org.springframework.orm.jpa.vendor.HibernateJpaDialect, the flushMode is changed to AUTO when beginning transaction
SessionImpl.setFlushMode(FlushMode) line: 1286
HibernateSessionProxy.setFlushMode(FlushMode) line: 381
SeamHibernateJpaDialect(HibernateJpaDialect).beginTransaction(EntityManager, TransactionDefinition) line: 60
JpaTransactionManager.doBegin(Object, TransactionDefinition) line: 326
JpaTransactionManager(AbstractPlatformTransactionManager).getTransaction(TransactionDefinition) line: 350
SpringTransaction.begin() line: 74
Unless the transaction definition is set to readOnly spring will change the flushMode to manual
HibernateJpaDialect:45
--------------------------------
public Object beginTransaction(EntityManager entityManager, TransactionDefinition definition)
throws PersistenceException, SQLException, TransactionException {
super.beginTransaction(entityManager, definition);
Session session = getSession(entityManager);
FlushMode flushMode = session.getFlushMode();
FlushMode previousFlushMode = null;
if (definition.isReadOnly()) {
// We should suppress flushing for a read-only transaction.
session.setFlushMode(FlushMode.MANUAL);
previousFlushMode = flushMode;
}
else {
// We need AUTO or COMMIT for a non-read-only transaction.
if (flushMode.lessThan(FlushMode.COMMIT)) {
session.setFlushMode(FlushMode.AUTO);
previousFlushMode = flushMode;
}
}
return new SessionTransactionData(session, previousFlushMode);
}
Perhaps SpringTransaction should set should pass readOnly transaction def to Spring when the flushMode is manual.
Current Workaround: use DefaultJpaDialect
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2423) checkEntityPermission only checks one method
by Andrew (JIRA)
checkEntityPermission only checks one method
--------------------------------------------
Key: JBSEAM-2423
URL: http://jira.jboss.com/jira/browse/JBSEAM-2423
Project: JBoss Seam
Issue Type: Bug
Components: Security
Affects Versions: 2.0.1.CR1
Environment: JPA on tomcat6
Reporter: Andrew
Priority: Critical
If an entity has more than one method marked as @PrePersist, only one method is used to check for security. All methods should be considered and the result "anded" together.
Code in the Identity bean only checks for a @Restrict on the first method found. In my case, I extend an object with a @PrePersist with no @Restrict. My entity has a method:
@PrePersist @PreUpdate @PreRemove @Restrict
public void beforeChange() {}
(everything is restricted except for read access)
According to the PrePersist documentation, multiple PrePersist methods are valid. There are workarounds, but this is dangerous code. If it were not for my unit tests it could have slipped through. The seam documentation does not mention this limitation
I marked this as critical as it creates security holes in the application.
Here is the relevant code:
public void checkEntityPermission(Object entity, EntityAction action)
{
isLoggedIn(true);
PersistenceProvider provider = PersistenceProvider.instance();
Class beanClass = provider.getBeanClass(entity);
if (beanClass != null)
{
String name = Seam.getComponentName(entity.getClass());
if (name == null) name = beanClass.getName();
Method m = null;
switch (action)
{
case READ:
m = provider.getPostLoadMethod(beanClass);
break;
case INSERT:
m = provider.getPrePersistMethod(beanClass);
break;
case UPDATE:
m = provider.getPreUpdateMethod(beanClass);
break;
case DELETE:
m = provider.getPreRemoveMethod(beanClass);
}
Restrict restrict = null;
if (m != null && m.isAnnotationPresent(Restrict.class))
{
restrict = m.getAnnotation(Restrict.class);
}
else if (entity.getClass().isAnnotationPresent(Restrict.class))
{
restrict = entity.getClass().getAnnotation(Restrict.class);
}
if (restrict != null)
{
if (Strings.isEmpty(restrict.value()))
{
checkPermission(name, action.toString(), entity);
}
else
{
checkRestriction(restrict.value());
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months