[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1855) FacesMessages.instance().addToControl and Datatable do not work properly
by Andy Bosch (JIRA)
FacesMessages.instance().addToControl and Datatable do not work properly
------------------------------------------------------------------------
Key: JBSEAM-1855
URL: http://jira.jboss.com/jira/browse/JBSEAM-1855
Project: JBoss Seam
Issue Type: Bug
Components: JSF
Affects Versions: 1.2.0.GA
Reporter: Andy Bosch
It is possible do add FacesMessages via the Seam functionality with FacesMessages.instance().addToControl. In the parameters you have to pass the component id. In the plain JSF way, you can add FacesMessages via FacesContext ... addMessage. In the JSF-way you have to pass the client-id.
With normal input components you can use both ways. But when you work with datatables, you MUST work with the client-id, the Seam-way with using only the component-id does NOT work.
Explanation: When using a datatable-tag, you only have one component. The renderer generates the various rows. In the component-tree there is yet only one component! If you want to add a FacesMessage to one row, you can only work with client-ids (because you have to include the row-index).
My wish: Please change FacesMessages.instance().addToControl. for using with client-ids.
--
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
15 years, 3 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2093) Optimize getting Id in Seam code for better performance
by Mikhail Grushinskiy (JIRA)
Optimize getting Id in Seam code for better performance
-------------------------------------------------------
Key: JBSEAM-2093
URL: http://jira.jboss.com/jira/browse/JBSEAM-2093
Project: JBoss Seam
Issue Type: Feature Request
Reporter: Mikhail Grushinskiy
This sequence of calls (used in PersistenceProvider) is quite slow
Entity.forClass(bean.getClass()).getIdentifier(bean);
1) Entity.forClass() is reading annotations using JDK 5 methods (JDK 5 annotation reading is not that fast). Can it be cached?
2) JDK 5 reflection is used to get bean id (which is slower than optmized reflection with cglib)
3) There could be other reasons as well. I think repetitive calling of this sequence under profiler will give better picture.
from PersistenceProvider.java
/**
* Get the value of the entity identifier attribute.
*
* @param bean a managed entity instance
*/
public Object getId(Object bean, EntityManager entityManager)
{
return Entity.forClass( bean.getClass() ).getIdentifier(bean);
}
/**
* Get the name of the entity
*
* @param bean
* @param entityManager
*/
public String getName(Object bean, EntityManager entityManager)
{
return Entity.forClass(bean.getClass()).getName();
}
/**
* Get the value of the entity version attribute.
*
* @param bean a managed entity instance
*/
public Object getVersion(Object bean, EntityManager entityManager)
{
return Entity.forClass( bean.getClass() ).getVersion(bean);
}
--
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
15 years, 4 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2255) Undeploying multiple wars inside an ear causes IllegalStateException.
by Richard Teviotdale (JIRA)
Undeploying multiple wars inside an ear causes IllegalStateException.
---------------------------------------------------------------------
Key: JBSEAM-2255
URL: http://jira.jboss.com/jira/browse/JBSEAM-2255
Project: JBoss Seam
Issue Type: Bug
Affects Versions: 2.0.0.GA
Environment: Debian GNU/Linux x86_64 2.6.18-4 SMP, Java 1.5.0_12, JBoss 4.2.1.GA, Seam 2.0.0.GA.
Reporter: Richard Teviotdale
When undeploying an ear that contains two wars an IllegalStateException is generated. I have not checked for more than two wars but I suspect an exception would be generated for each undeploying war after the first. This exception does not prevent the server from undeploying and redeploying the ear, it just produces an error and stacktrace in the server log.
Here's how to duplicate.
- make a generic seam-gen project called test deployed as an ear
- ant explode
- go to $JBOSS_HOME/default/deploy/test.ear
- recursive copy test.war directory to test2.war
- edit META-INF/application.xml and create deploy entry for test2.war
- run server
- touch META-INF/application.xml
see server log for following stack trace:
15:05:11,798 INFO [TomcatDeployer] undeploy, ctxPath=/test2, warUrl=.../deploy/test.ear/test2.war/
15:05:12,067 INFO [TomcatDeployer] undeploy, ctxPath=/test, warUrl=.../deploy/test.ear/test.war/
15:05:12,068 ERROR [[/test]] Session event listener threw exception
java.lang.IllegalStateException: Attempted to invoke a Seam component outside the an initialized application
at org.jboss.seam.contexts.Lifecycle.getApplication(Lifecycle.java:36)
at org.jboss.seam.contexts.Lifecycle.endSession(Lifecycle.java:220)
at org.jboss.seam.contexts.ServletLifecycle.endSession(ServletLifecycle.java:129)
at org.jboss.seam.servlet.SeamListener.sessionDestroyed(SeamListener.java:49)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:702)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:660)
snip...
15:05:12,276 ERROR [[/test]] Exception sending context destroyed event to listener instance of class org.jboss.seam.servlet.SeamListener
java.lang.IllegalStateException: Attempted to invoke a Seam component outside the an initialized application
at org.jboss.seam.contexts.Lifecycle.getApplication(Lifecycle.java:36)
at org.jboss.seam.contexts.Lifecycle.endApplication(Lifecycle.java:50)
at org.jboss.seam.contexts.ServletLifecycle.endApplication(ServletLifecycle.java:118)
at org.jboss.seam.servlet.SeamListener.contextDestroyed(SeamListener.java:39)
at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3893)
--
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
15 years, 5 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-967) JBoss Seam - Support authentication from a realm (on Tomcat)
by Bradley Smith (JIRA)
JBoss Seam - Support authentication from a realm (on Tomcat)
------------------------------------------------------------
Key: JBSEAM-967
URL: http://jira.jboss.com/jira/browse/JBSEAM-967
Project: JBoss Seam
Issue Type: Feature Request
Components: Security
Reporter: Bradley Smith
Please see discussion in the JBoss forum reference.
The idea is to allow the Seam Identity (security) component to get the Principal from the HttpServletRequest and to delegate the hasRole() calls to the HttpServletRequest as well. This is because, in my case, Tomcat has already forced the user to authenticate if necessary and the authentication, authorization information is available in the container's HttpServletRequest impl.
Principal userPrincipal = httpServletRequest.getUserPrincipal();
boolean hasRole(String roleName) {
return httpServletRequest.isUserInRole(roleName);
}
public String getUsername() {
return httpServletRequest.getRemoteUser();
}
public boolean isLoggedIn() {
return httpServletRequest.getUserPrincipal() != null;
}
--
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
15 years, 6 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2232) Reduce debug log level for events
by Christian Bauer (JIRA)
Reduce debug log level for events
---------------------------------
Key: JBSEAM-2232
URL: http://jira.jboss.com/jira/browse/JBSEAM-2232
Project: JBoss Seam
Issue Type: Task
Components: Core
Reporter: Christian Bauer
Priority: Critical
Debug logging with Seam 2.x is completely useless. The most critical information in the debug log is the instantiation and lookup of components, however, if you enable DEBUG for
org.jboss.seam.Component, you get thousands of these:
12:26:06,282 DEBUG [Component] instantiating Seam component: org.jboss.seam.core.events
12:26:06,282 DEBUG [Component] initializing new instance of: org.jboss.seam.core.events
12:26:06,282 DEBUG [Component] done initializing: org.jboss.seam.core.events
We need to exclude the event firing from debug logging, even if we hardcode it. And, are these events really useful? I have no idea why and when I'd want to listen to "context variable initialized" events.
--
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
15 years, 7 months