April 2008 - seam-issues - Jboss List Archives

[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, 5 months

7
18
0 / 0

[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, 6 months

4
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1486) Posibility to configure session scope type when in portlet environment

by ivica c (JIRA)

Posibility to configure session scope type when in portlet environment ---------------------------------------------------------------------- Key: JBSEAM-1486 URL: http://jira.jboss.com/jira/browse/JBSEAM-1486 Project: JBoss Seam Issue Type: Feature Request Affects Versions: 1.3.0.ALPHA Reporter: ivica c Fix For: 1.3.0.GA It would be nice to have a possibility to define the session scope type in the portlet environment: portlet scope or application scope. It affects not only seam session scope but also the conversation scope because the conversation scope internally uses the session scope. Now, seam components can be saved only in the portlet session scope so it is not possible to share data between portlets. If there is possibility to set components can be saved in the application scope, then data will be able to be shared between portlets in the same war. -- 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

4
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2579) Messages.properties do not work as expected with multiple WARs inside multiple Seam EARs

by Reind D (JIRA)

Messages.properties do not work as expected with multiple WARs inside multiple Seam EARs ---------------------------------------------------------------------------------------- Key: JBSEAM-2579 URL: http://jira.jboss.com/jira/browse/JBSEAM-2579 Project: JBoss Seam Issue Type: Bug Components: JSF Integration Affects Versions: 2.0.1.GA Environment: JBoss 4.2.2 Reporter: Reind D When 2 Seam apps are deployed, both with multiple WARs each of which as a WEB-INF/classes/messages.properties file, the messages for one of the web contexts will not work. Instead, the messages for the other WAR in the same EAR will be displayed. I've attached a sample application that demonstrates this behavior. It is modified from the "Registration" example. Steps: 1) Untar the archive 2) Copy to the app server's deploy directory 3) Go to the following URLs: http://localhost:8080/a/register.seam http://localhost:8080/b/register.seam http://localhost:8080/c/register.seam http://localhost:8080/d/register.seam The 'expected' and 'actual' fields should always match, but they won't in 1 case. -- 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

3
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2797) There should be one ResourceLoader per module inside an EAR

by Gregory Tanneau (JIRA)

There should be one ResourceLoader per module inside an EAR ----------------------------------------------------------- Key: JBSEAM-2797 URL: http://jira.jboss.com/jira/browse/JBSEAM-2797 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 2.0.1.GA Environment: Windows XP, Seam 2.0.1.GA with JBoss 4.2.1.GA Reporter: Gregory Tanneau According to the following scenario : One MAIN.EAR with tow web modules - APP1.WAR (with messages_one_xx.properties) - APP2.WAR (with messages_two_xx.properties) When starting JBoss, the first webapp accessed makes the Resource Loader search for bundles (ie. I access APP1, messages_one_xx.properties are found). When the second webapp is accessed, the Resource Loader assumes bundles are already loaded (messages_two are NOT loaded). I think there should be (in this cas) TWO ResourceLoaders, one per web module. -- 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

7
12
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1913) EL with parameters not work in a <ui:composition> facelet component

by Gilliard Cordeiro (JIRA)

EL with parameters not work in a <ui:composition> facelet component ------------------------------------------------------------------- Key: JBSEAM-1913 URL: http://jira.jboss.com/jira/browse/JBSEAM-1913 Project: JBoss Seam Issue Type: Bug Components: EL Affects Versions: 1.2.1.GA Environment: Windows or Linux, Java 6, Tomcat 6.0.14 Reporter: Gilliard Cordeiro EL with parameters not work in a <ui:composition> facelet component. The value of parameters is available in a <h:outputText>, for instance, but is null when executing a Java action methods. -- 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

4
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2385) EL parsing ?: poorly

by David Fedchenko (JIRA)

EL parsing ?: poorly -------------------- Key: JBSEAM-2385 URL: http://jira.jboss.com/jira/browse/JBSEAM-2385 Project: JBoss Seam Issue Type: Bug Components: EL Affects Versions: 2.0.1.CR1 Environment: Win XP, JBoss AS 4.2.2.GA Reporter: David Fedchenko Priority: Minor This throws an exception: #{referralController.newReferral ? messages.referralTitleNew: messages.referralTitleExisting} It can be avoided by adding a space before the colon. -- 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

3
3
0 / 0

[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

4
14
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2523) Identity component should be scoped to the WAR module

by Reind D (JIRA)

Identity component should be scoped to the WAR module ----------------------------------------------------- Key: JBSEAM-2523 URL: http://jira.jboss.com/jira/browse/JBSEAM-2523 Project: JBoss Seam Issue Type: Bug Components: Security Affects Versions: 2.0.1.CR1 Environment: JBoss 4.2.2.GA (also tested on 4.2.0.GA) Reporter: Reind D I have an EAR with two web modules. I have configured the 'Identity authenticateMethod' in components.xml to use a different a method for each WAR (authA.authenticate, authB.authenticate). When attempting to login to the 'b' webapp it invokes the authenticateMethod defined in a.war. Attempting to login to the 'a' webapp works as expected. It appears as though the Identity component is not scoped to the WAR. The EAR is packaged as follows: my-application.ear/ a.war/ WEB-INF/ components.xml ... b.war/ WEB-INF/ components.xml ... web.jar Congure authentication as follows in both components.xml files: a.war/WEB-INF/components.xml <security:identity authenticate-method="#{authA.authenticate}" /> b.war/WEB-INF/components.xml <security:identity authenticate-method="#{authB.authenticate}" /> -- 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

6
16
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2854) Provide a way to nest pageflows

by Marcell Barbacena (JIRA)

Provide a way to nest pageflows ------------------------------- Key: JBSEAM-2854 URL: http://jira.jboss.com/jira/browse/JBSEAM-2854 Project: JBoss Seam Issue Type: Feature Request Components: BPM, Core, JSF Controls Affects Versions: 2.0.1.GA Environment: All Reporter: Marcell Barbacena The current behaviour of pageflow subprocess tag is to include the pageflow definition in the the current flow, meaning that the parent pageflow is paused until the included pageflow ends. However, sometimes it is desired that the parent pageflow do not "pause" and that the included gain its own flow. The semantics of this nested pageflow is: - when starts: provided a nested conversation from the parent pageflow. - when ends: go back do the state before the nesting. If the parent pageflow is not associated in any way to the nested, its flow goes without interfering with the nested. E.g.: Parent directed graph: startpage1->page1; page1->page2; page1->nested; nested->page2; page2->page3; page3->endpage1; Nested graph: startpage2->page5; page5->page6; page6->endpage2 Then we can have: parent: startpage1->page1; parent: page1->nested; nested: startpage2->page5; nested: page5->page6; parent: page1->page2; parent: page2>page3; nested: page6->endpage2 nested:endpage2->page2; parent: page3->endpage1; nested: page2>page3; nested: page3->endpage1; See that the nested pageflow gains his own flow, i.e. independent of the parent. -- 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

4
5
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues April 2008