May 2007 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1311) build.xml: Target explode: Copying of EAR doesn't work when the source-EAR already exists

by Mark Schmatz (JIRA)

build.xml: Target explode: Copying of EAR doesn't work when the source-EAR already exists ----------------------------------------------------------------------------------------- Key: JBSEAM-1311 URL: http://jira.jboss.com/jira/browse/JBSEAM-1311 Project: JBoss Seam Issue Type: Bug Affects Versions: 1.2.1.GA Environment: Mac Tiger, Eclipse 3.2.2, Eclipse 3.3M6, Eclipse 3.3M7 Reporter: Mark Schmatz During the explode target the EAR is not copied to the deploy-dir if ithe source-EAR already exists. Below if pasted the original target source code produced by Seam-gen 1.2.1 with my little bug fix. The bug fix is enclosed with the "NEW NEW NEW..." comment and just deletes the source-EAR after copying. <target name="explode" depends="jar,war,ear,datasource" description="Deploy the exploded archive"> <fail unless="jboss.home">jboss.home not set</fail> <mkdir dir="${jar.deploy.dir}"/> <mkdir dir="${war.deploy.dir}"/> <copy todir="${jar.deploy.dir}"> <fileset dir="${jar.dir}"/> </copy> <copy todir="${war.deploy.dir}"> <fileset dir="${war.dir}"/> </copy> <copy todir="${ear.deploy.dir}"> <fileset dir="${ear.dir}"/> </copy>  <delete dir="${ear.dir}" />  </target> -- 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

17 years, 7 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1306) EntityQuery: last page is empty for even number of results

by H T (JIRA)

EntityQuery: last page is empty for even number of results ---------------------------------------------------------- Key: JBSEAM-1306 URL: http://jira.jboss.com/jira/browse/JBSEAM-1306 Project: JBoss Seam Issue Type: Bug Components: Framework Affects Versions: 1.3.0.BETA1 Environment: JBoss 4.2CR2 Latest CVS Build (as of May 8, 2007) Reporter: H T In the Contact List example, add another contact entry into import.sql to make 4. Modify "max-results" in components.xml to 2. When you click on last page, it shows an empty page. -- 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

17 years, 7 months

2
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1243) Ending nested conversation causes issues with pages.xml and rendering the same view again

by Andrew (JIRA)

Ending nested conversation causes issues with pages.xml and rendering the same view again ----------------------------------------------------------------------------------------- Key: JBSEAM-1243 URL: http://jira.jboss.com/jira/browse/JBSEAM-1243 Project: JBoss Seam Issue Type: Bug Affects Versions: 1.1.6.GA Reporter: Andrew See JBoss Forum Reference of this bug. Will try to attach reproduce code in a bit. -- 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

17 years, 7 months

2
7
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1309) Hook Faces Application.createValueBinding / createMethodBinding so that the Expression Language enhancements are available to all bindings created

by Chris Rudd (JIRA)

Hook Faces Application.createValueBinding / createMethodBinding so that the Expression Language enhancements are available to all bindings created -------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBSEAM-1309 URL: http://jira.jboss.com/jira/browse/JBSEAM-1309 Project: JBoss Seam Issue Type: Feature Request Affects Versions: 1.2.1.GA Reporter: Chris Rudd Currently the expression language extensions are only available from facelets views. If the Faces Application is hooked into then the createMethodBinding/createValueBinding can be extended to support the extensions as well. The issue is that currently you cannot do this : FacesContext.getCurrentInstance().getApplication().createValueBinding("#{s:hasPermission('g','g',null)}"); Likewise if you are in a faces request this also failes (due to it delegating to the facesContext) Expressions.instance().createValueBinding("#{s:hasPermission('g','g',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

17 years, 7 months

2
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1334) Improve SeamVariableResolver to allow jbpm and seam variables/components... to be resolved

by Manfred Moser (JIRA)

Improve SeamVariableResolver to allow jbpm and seam variables/components... to be resolved ------------------------------------------------------------------------------------------ Key: JBSEAM-1334 URL: http://jira.jboss.com/jira/browse/JBSEAM-1334 Project: JBoss Seam Issue Type: Feature Request Components: BPM Affects Versions: 1.2.0.GA Reporter: Manfred Moser The class org.jboss.seam.jbpm.SeamVariableResolver does not look up jbpm variables in a workflow and it is therefore not possible to use el in jpdl to get access to jbpm variables. The resolver should look up in the seam as well as the jbpm context. We have developed a fix as explained in the forum post here http://www.jboss.com/index.html?module=bb&op=viewtopic&t=105448 I will try to attach the files to this issue or have a comment per file. -- 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

17 years, 7 months

2
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1332) Init.instance() causes (unecessary) lock contention under heavy load.

by Radu Aghinii (JIRA)

Init.instance() causes (unecessary) lock contention under heavy load. --------------------------------------------------------------------- Key: JBSEAM-1332 URL: http://jira.jboss.com/jira/browse/JBSEAM-1332 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.2.1.GA, 1.2.0.GA Environment: Jboss AS 4.0.5GA , Sun jdk 1.5.0_11 , JSF RI 1.2 b4, Linux FC 5 running 2.5.15.2054_FC5 SMP , Dual Intel Xeons w/ HT enabled. (linux sees 4 cpus); Note that the tomcat instance is modified as described in the associated forum post. Reporter: Radu Aghinii Under heavy load the variation of response time for identical seam requests gets very large. For my app, for example, under heavy load some requests will take 5 seconds to finish while others take 5 minutes. Check the associated forum post for a more narrative story that motivated this investigation but the long and the short of it is that my app ( and i suspect any seam app) calls Init.instance() a LOT ( ~100K times per request). The current implementation of it just: Init init = (Init) Contexts.getApplicationContext().get(Init.class); which looks up the seam component name for the Init class and then looks up the component by name. The problem is that the name lookup uses java.lang.Class.getAnnotation() which internally calls the synchronized method "initAnnotationsIfNecessary()". Under heavy load i found most of the jboss request threads waiting to lock that lock. Replacing the body of Init.instance() to skip the name lookup and just do: Init init = (Init) Contexts.getApplicationContext().get("org.jboss.seam.core.init") resulted in much improved behavior. Before this change, once the machine was loaded to the point where requests were taking generally taking 5-10 seconds SOME connections would take a few minutes (capped at 300 seconds due to some timeout either in jboss or apache). Now that performance is pretty bad for a web app, but even transient conditions such as GC, traffic spikes and DB locks would induce the condition. Further, especially when this happened under moderate general load, the machine wouldn't recover, but rather the number of concurrent connections would climb, the performance per requests would fall further and eventually the jvm would run out of memory. With the change in place the machines recover. Even when the average requests are taking 20-30 seconds (a very high load situation, but we see it due to the transients mentioned above) the slowest requests are in the 1minute to 2 minute range and, most importantly, the machine recovers pretty quickly. -- 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

17 years, 7 months

3
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1302) Conversion support for selectMany for Set implementation

by H T (JIRA)

Conversion support for selectMany for Set implementation -------------------------------------------------------- Key: JBSEAM-1302 URL: http://jira.jboss.com/jira/browse/JBSEAM-1302 Project: JBoss Seam Issue Type: Bug Components: JSF Affects Versions: 1.2.1.GA Environment: Latest Seam CVS build Jboss AS 4.2CR2 Reporter: H T The selectMany in the UI example works well for a List implementation; however, a conversion error arises if the List implementation was changed to a Set implementation. -- 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

17 years, 7 months

4
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1327) hot deployment directory should not be tied to name and location of debug jar

by Dan Allen (JIRA)

hot deployment directory should not be tied to name and location of debug jar ----------------------------------------------------------------------------- Key: JBSEAM-1327 URL: http://jira.jboss.com/jira/browse/JBSEAM-1327 Project: JBoss Seam Issue Type: Feature Request Components: Core Affects Versions: 1.2.1.GA Environment: JDK 1.5, Ubuntu Linux 7.04, Jetty running under Maven 2 Reporter: Dan Allen Priority: Critical Fix For: 1.3.0.BETA1 The logic for determining the location of the hot deployable directory for Java classes currently relies on the location and name of the jboss-seam-debug jar file. While this may work when the jar file is placed in WEB-INF/lib, relative to the WEB-INF/dev directory, and named jboss-seam-debug.jar, it breaks down when it is loaded by the application server by a different means or has a different name. For instance, when running a Seam application using Jetty from within Maven 2, the location of the jar file is in the local repository. What I find particularly scary is the hard-coded string offsets: String hotDeployDirectory = path.substring( 9, path.length()-46 ) + "dev"; To get a better understanding of the problem, I added some logging messages to capture the path resolver logic when jetty builds its classpath from the maven repository. META-INF/debug.xhtml detected at jar:file:/home/dallen/.m2/repository-public/jboss/seam/jboss-seam-debug/1.2.1.GA/jboss-seam-debug-1.2.1.GA.jar!/META-INF/debug.xhtml Hot deploy directory is /home/dallen/.m2/repository-public/jboss/seam/jboss-seam-debug/1.2.1.GA/jbossdev If I place the jboss-seam-debug-1.2.1.ga.jar file in the src/main/webapp/WEB-INF/lib directory, then things get a little bit better, but still not quite right. META-INF/debug.xhtml detected at jar:file:/home/dallen/projects/connoisseur/src/main/webapp/WEB-INF/lib/jboss-seam-debug-1.2.1.GA.jar!/META-INF/debug.xhtml Hot deploy directory is /home/dallen/projects/connoisseur/src/main/webapp/WEB-INF/lib/jbossdev What I propose is for the WEB-INF/dev directory to be loaded using the servlet context. That way, it will always be the directory that is most likely located in the project of the developer. Since this feature is intended strictly for development, this seams to make the most sense. I will provided a patch for both Seam 1.2.1.ga and the trunk. -- 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

17 years, 7 months

2
11
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1325) Entity component does not properly cache Entity instances in application context

by Chris Rudd (JIRA)

Entity component does not properly cache Entity instances in application context -------------------------------------------------------------------------------- Key: JBSEAM-1325 URL: http://jira.jboss.com/jira/browse/JBSEAM-1325 Project: JBoss Seam Issue Type: Bug Affects Versions: 1.2.1.GA, 1.2.0.GA Reporter: Chris Rudd The Entity.forClass method does not put the newly created Entity instance into the application context corectly. In the set its using set(name, model) instead of set(name,entity). public static Entity forClass(Class clazz) { if ( !Contexts.isApplicationContextActive() ) { throw new IllegalStateException("No application context active"); } String name = getModelName(clazz); Model model = (Model) Contexts.getApplicationContext().get(name); if ( model==null || !(model instanceof Entity) ) { Entity entity = new Entity(clazz); Contexts.getApplicationContext().set(name, model); return entity; } else { return (Entity) model; } } -- 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

17 years, 7 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1328) @Factory method called first

by Mahesh Shinde (JIRA)

@Factory method called first ---------------------------- Key: JBSEAM-1328 URL: http://jira.jboss.com/jira/browse/JBSEAM-1328 Project: JBoss Seam Issue Type: Bug Components: JSF Affects Versions: 1.2.1.GA Environment: Windows 2000, jboss-4.2.0.CR1 Reporter: Mahesh Shinde Priority: Critical I am injecting some parameters which should be first get injected and then @Factory methd should called to consider injected parameter as filter for populating data from @Factory method. But My @Factory method is always get called first and then injecting parameter which has no use. And I also observed that @Factory method should called only once for one request , but it is calling for more that one time.... It reduces the preformance of system. Suggest what to do!. -- 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

17 years, 7 months

2
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues May 2007