November 2008 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3519) Excessive JNDI lookups for "java:comp/UserTransation"

by Jay Balunas (JIRA)

Excessive JNDI lookups for "java:comp/UserTransation" ----------------------------------------------------- Key: JBSEAM-3519 URL: https://jira.jboss.org/jira/browse/JBSEAM-3519 Project: Seam Issue Type: Bug Components: Core, Performance and Scalability Affects Versions: 2.1.0.CR1 Reporter: Jay Balunas Assignee: Shane Bryzak Priority: Critical Fix For: 2.1.1.CR1 NOTE: There are more details to this on the seam-dev email list and its archives. Below is the primary email that broke down the behavior. A single user making a single request to the Seam wiki example's user forum front page performs 114 JNDI lookups for "java:comp/UserTransation". This means that not only are 144 instances of IntialContext created, but we have 114 actual lookups as well. This is nearly linear with 2 requests creating 228 JNDI lookups + some for ajax4jsf caching calls as described below. Extrapolating to the 25 user test that would be 25x114=2850 jndi lookups for each round of requests. At least for the wiki page I am testing there were no other JNDI lookups. Who is looking up "java:comp/UserTransation" -------------------------------------------------------- All of these calls can be traced to Transaction.instance(). I broke down all of the calls to Transaction.instance() during a single request to the user forum page on the wiki. 81 - seam.util.Work.workInTransaction(Work.java:34) via (TransactionInterceptor.java:34) 1 - SeamPhaseListener.handleTransactionsBeforePhase(SeamPhaseListener.java:319) 3 - SeamPhaseListener.begin(SeamPhaseListener.java:591) 3 - SeamPhaseListener.begin(SeamPhaseListener.java:594) 3 - SeamPhaseListener.commitOrRollback(SeamPhaseListener.java:611) 3 - SeamPhaseListener.commitOrRollback(SeamPhaseListener.java:614) 8 - ManagedPersistenceContext.joinTransaction(ManagedPersistenceContext.java:120) 6 - Contexts.flushAndDestroyContexts(Contexts.java:331) 6 - ManagedPersistenceContext.close(ManagedPersistenceContext.java:192) ------------- 114 - Total I then broke it down by which JSF lifecycle phase it was done in. Phase Breakdown: ------------------ 3 - During RESTORE_VIEW 2 - Between RESTORE_VIEW and RENDER_RESPONSE 91 - During RENDER_RESPONSE 18 - After RENDER_RESPONSE ---------- 114 total I then did the same break down on a second follow up request with the same session Second Request showed a different distribution: ------------------------------------------------ 3 - During RESTORE_VIEW 2 - Between RESTORE_VIEW and RENDER_RESPONSE 91 - During RENDER_RESPONSE 5 - After RENDER_RESPONSE 3 - During 2nd RESTORE_VIEW 0 - Between 2nd RESTORE_VIEW and RENDER_RESPONSE 1 - During 2nd RENDER_RESPONSE 3 - After 2nd RENDER_RESPONSE 3 - During 3rd RESTORE_VIEW 0 - Between 3rd RESTORE_VIEW and RENDER_RESPONSE 1 - During 3rd RENDER_RESPONSE 16 - After 3rd RENDER_RESPONSE ------------ 128 total The extra 14 lookups are all during the extra 2 mini requests. They all pass through this ajax4jsf class "org.ajax4jsf.resource.ResourceLifecycle.invokePhaseListener(ResourceLifecycle.java:[199/201])". I'm assuming that these extra calls are related to page fragment caching and/or resources that are provided through the ajax4jsf InternetResourceService. Christian can you confirm? Conclusions: --------------------- We obviously need to find more ways to improve this behavior. The primary offender is "Work.java" (see: http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/util/W... ). This single line is checking if the transaction is currently active. 81 time it is active and processing continues as normal. Is there a way we can cache this value for the length of the request (either the transaction, or the result)? Caching the result could be bad if something changed during the request, so we would need the actual transaction. Also many of the lookups were the result of EL processing during the RENDER_RESPONSE phase. Ideally these would primarily be read-only requests or close to it. Could there be a way to disable the transactional calls for items somehow tagged read only? I have not give that much thought yet so it might need some flushing out ;-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

4
7
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3558) Document conversation-required attribute in pages.xml

by Shane Bryzak (JIRA)

Document conversation-required attribute in pages.xml ----------------------------------------------------- Key: JBSEAM-3558 URL: https://jira.jboss.org/jira/browse/JBSEAM-3558 Project: Seam Issue Type: Task Components: Documentation Issues Affects Versions: 2.1.0.CR1 Reporter: Shane Bryzak Assignee: Shane Bryzak Priority: Minor Fix For: 2.1.1.CR1 We don't document this attribute clearly anywhere in the docs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

1
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3485) Optimize how the InitialContext is created in org.jboss.seam.util.Naming

by Jay Balunas (JIRA)

Optimize how the InitialContext is created in org.jboss.seam.util.Naming ------------------------------------------------------------------------ Key: JBSEAM-3485 URL: https://jira.jboss.org/jira/browse/JBSEAM-3485 Project: Seam Issue Type: Task Components: Core Affects Versions: 2.1.0.BETA1 Reporter: Jay Balunas Fix For: 2.1.1.CR1 Attachments: patch.txt Seam currently only creates and manages the InitialContext in the "org.jboss.seam.util.Naming" class (see: http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/util/N... ). The properties are set in one location and done only once during the initialization of seam (see: http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/init/I... ). I see two issues here although they are related. The first issue would require some caching mechanism or logic for reuse of the InitialContext instance instead of recreating it every time. WE need to determine when it makes sense to reuse an instance of the InitialContext, and when we need to get it fresh. We currently use they exact same properties to initialize it and those are set during Seam initialization and do not appear to ever change once created. The second issue is that we do a certain amount of processing every time the context is requested, this could be optimized. Currently I see a few blocked threads on the "props.size()" call in the Naming class which is a synchronized method on the Hashtable. We need to maintain the logic that if the property list is empty we continue to call "new InitialContext()" and not pass in the properties object. This is because the first thing the InitialContext constructor does with a properties object is clone it which can be costly. This change is not as important if we find a way to cache the initial context. I have attached a patch that implements these changes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

2
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3609) Performance problem: when using <s:link> or <s:button> with page.xml

by kun zhang (JIRA)

Performance problem: when using <s:link> or <s:button> with page.xml -------------------------------------------------------------------- Key: JBSEAM-3609 URL: https://jira.jboss.org/jira/browse/JBSEAM-3609 Project: Seam Issue Type: Bug Affects Versions: 2.0.3.CR1, 2.0.2.SP1 Environment: JDK 1.5.0_14, jboss-4.2.3.GA Reporter: kun zhang Priority: Critical <s:link> or <s:button> will automatically check the View_id's page.xml, and temporary construct the seam components in the page.xml, then call component's @Create and @Destroy method. For example: There is a <s:link> at the menu.xhtml: <s:link view="/login.xhtml" value="Login"/> If login.page.xhtml like this: <param name="order" value="#{deptList.order}"/> seam will automatically construct the deptList component, and call it's @Create and @Destroy method. I find the issue at Seam 2.0.2.SP1 and 2.0.3.CR1. It's a big performance problem, please resolve it ASAP. Thanks a lot and sorry for my bad english. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

5
13
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3693) Suppression of individual parameters should call setter with null as a parameter

by Francisco Jose Peredo Noguez (JIRA)

Suppression of individual parameters should call setter with null as a parameter -------------------------------------------------------------------------------- Key: JBSEAM-3693 URL: https://jira.jboss.org/jira/browse/JBSEAM-3693 Project: Seam Issue Type: Bug Affects Versions: 2.0.2.SP1 Reporter: Francisco Jose Peredo Noguez The suppression of individual parameters, like this: <s:link view-id="/foo.xhtml"> <f:param name="suppressedParameter" value="#{null}"/> </s:link> or like this: <s:link view-id="/foo.xhtml"> <f:param name="suppressedParameter"/> </s:link> Does not really work as intuitively expected: when I write <f:param name="suppressedParameter" value="#{null}"/> or <f:param name="suppressedParameter"/> I expect to have the method "setSuppressedParameter" called with null as a parameter, but org.jboss.seam.navigation.Pages.applyConvertedValidatedValuesToModel there is a conditional that prevents that from happening (See JBSEAM-3454), what really happens is that setSuppressedParameter is never called. It think the right behavior would be a call to setSuppressedParameter with null as a parameter. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

1
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3692) Seam 2.1.0.SP1 generate-ui fails

by Tony Kay (JIRA)

Seam 2.1.0.SP1 generate-ui fails -------------------------------- Key: JBSEAM-3692 URL: https://jira.jboss.org/jira/browse/JBSEAM-3692 Project: Seam Issue Type: Bug Components: Tools Affects Versions: 2.1.0.SP1 Environment: Seam 2.1.0.SP1, Icefaces 1.7.2, Jboss AS 4.2.2 Reporter: Tony Kay My application runs fine (schema generation works, deployment works, existing code runs); however, running seam generate-ui produces the following error: [hibernate] An exception occurred while running exporter #2:generic exportertemplate: view/list.xhtml.ftl [hibernate] To get the full stack trace run ant with -verbose [hibernate] org.hibernate.tool.hbm2x.ExporterException: Error while processing Entity: com.therapysites.cms.entity.Theme with template view/list.xhtml.ftl [hibernate] freemarker.core.InvalidReferenceException: Expression property.value.typeName is undefined on line 27, column 18 in util/TypeInfo.ftl. BUILD FAILED /Users/tonykay/seam/seam-gen/build.xml:1145: org.hibernate.tool.hbm2x.ExporterException: Error while processing Entity: com.therapysites.cms.entity.Theme with template view/list.xhtml.ftl I've tried removing various mappings in the Theme class to see what is causing it, but nothing I do seems to help. Is there any way to get the property name that was being evaluated when it pukes? Here are some of the classes, in case there is something obvious: The Theme class looks like this: @Entity public class Theme implements Serializable { private Long id; private Integer version; private String name; private Design design; private OverrideSet overrides; public Theme() { overrides = new OverrideSet(); } @Id @GeneratedValue @Column(name = "theme_id") public Long getId() { return id; } public void setId(Long id) { this.id = id; } @Version @Column(columnDefinition = "integer not null default 0") public Integer getVersion() { return version; } private void setVersion(Integer version) { this.version = version; } @Length(min = 1, max = 40) @NotNull public String getName() { return name; } public void setName(String name) { this.name = name; } @ManyToOne @NotNull @ForeignKey(name = "fk_theme_design") @JoinColumn(name = "design_id") public Design getDesign() { return design; } public void setDesign(Design design) { this.design = design; } @NotNull public OverrideSet getOverrides() { return overrides; } public void setOverrides(OverrideSet overrides) { this.overrides = overrides; } } and the Design class has this: @OneToMany(mappedBy="design", cascade=CascadeType.ALL) public Set<Theme> getThemes() { return themes; } public void setThemes(Set<Theme> themes) { this.themes = themes; } The OverrideSet is an Embeddable with the following form: @Embeddable public class OverrideSet implements Serializable { private static Log log = Logging.getLog(OverrideSet.class); private Map<String, ColorOverride> colors = null; private Set<ColorOverride> colorSet = new HashSet<ColorOverride>(); @Transient private <T extends ParameterOverride> void rebuildMap(Map<String, T> map, Set<T> set) { map.clear(); for(T p : set) { map.put(p.getName(), p); } } @Transient public Map<String, ColorOverride> getColors() { if(colors == null) { // Only rebuild if it does not exist! colors = new HashMap<String, ColorOverride>(); rebuildMap(colors, colorSet); } return colors; } @CollectionOfElements @JoinTable(joinColumns = @JoinColumn(name = "owner_id"), inverseJoinColumns = @JoinColumn(name = "override_id")) public Set<ColorOverride> getColorSet() { return colorSet; } public void setColorSet(Set<ColorOverride> colorSet) { this.colorSet = colorSet; } public void setColors(Map<String, ColorOverride> colors) { this.colors = colors; } // Other kinds of overrides (images, etc), but just repeated form } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3691) Seam Excel header for center facet does not work

by Ted Jenkins (JIRA)

Seam Excel header for center facet does not work ------------------------------------------------ Key: JBSEAM-3691 URL: https://jira.jboss.org/jira/browse/JBSEAM-3691 Project: Seam Issue Type: Bug Components: Excel Reporter: Ted Jenkins When using Seam Excel functionality, and including a worksheet header for the center facet, it will not show in the exported Excel file. Here's what I've done to make this work: -In UIHeader.java, changed the static CENTER_FACET from "center" to "centre". -In JXLFactory.java, changed the call in createHeaderFooter() to processHeaderFooter from uiHeaderFooter.getFacet("middle") to uiHeaderFooter.getFacet("centre") -Implemented the header tag with a facet of "centre" rather than "center" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2933) Seam 2.1-snapshot, gwt1.5m2, array issues

by darren hartford (JIRA)

Seam 2.1-snapshot, gwt1.5m2, array issues ----------------------------------------- Key: JBSEAM-2933 URL: http://jira.jboss.com/jira/browse/JBSEAM-2933 Project: Seam Issue Type: Bug Components: GWT Reporter: darren hartford There are some problems with Arrays of DTO's between seam 2.1-snapshot (4/25/2008) and GWT 1.5m2 remoting/rpc. i.e. SimpleDTO[] getMyDtoArray() It is the non-informative 'IncompatibleRemoteServiceException' error and mentions the application out of date, which it is not. No sample project or test case yet as mentioned in the forum post just identified the source of some problems. -- 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

5
8
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3483) conditional PARAM tag in .page.xml

by Terry (JIRA)

conditional PARAM tag in .page.xml ---------------------------------- Key: JBSEAM-3483 URL: https://jira.jboss.org/jira/browse/JBSEAM-3483 Project: Seam Issue Type: Feature Request Reporter: Terry Priority: Minor Fix For: 2.1.0.GA It would be really useful if PARAM tag in .page.xml supports "if" attribute so that it can be rendered conditionally. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

5
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3660) Add option to move Seam imported namespaces into a CompositeNamespace

by Michael Youngstrom (JIRA)

Add option to move Seam imported namespaces into a CompositeNamespace --------------------------------------------------------------------- Key: JBSEAM-3660 URL: https://jira.jboss.org/jira/browse/JBSEAM-3660 Project: Seam Issue Type: Feature Request Components: EL Affects Versions: 2.0.3.CR1 Reporter: Michael Youngstrom Assignee: Michael Youngstrom Fix For: 2.1.1.CR1 In some profiling I've done recently SeamELResolver is a major hot spot. In the current SeamELResolver code the resolver currently checks the root namespace to resolve the property. If it is not found there then the SeamELResolver will check all of the imported namespaces to see if the value can be resolved by prepending the namespace. In Seam 2.0.3 this results in 14 calls to Contexts.lookupInStatefulContexts() which is a rather expensive operation since it asks each one of the 8 scopes for the value. Often times each check involves several string appends and several hashmap lookups. If most of the el requests are user defined seam components this is not much of a problem. However, frequently this is not the case. For example, In an h:dataTable every time the "var" value is requested in an expresion it will have to go through all 14 Contexts.lookupInStatefulContexts() every time since it will not find the dataTable var in any of the seam scopes. Same thing for the s:selectItems component. A great component but it makes 5 or so EL requests for each option in the list which can begin to add up quickly. Another case is people who are using Spring (my problem) :). I think it would be a good idea to add an option to make SeamELResolver a better citizen in the ELResolver chain. One way to do this is to add an option to core:init that would move all Seam imported namespaces into a single child namespace. the option could look like this: <init:core core-imported-prefix="seam"/> This would be completely optional. It would move all namespaces that begin with "org.jboss.seam" into a seam composite namespace. The only impact it would have is that the developer would need to prefix the standard component with "seam." like #{seam.locale}. There are not a lot of standard seam components that are frequently accessed through EL. #{seam.messages} comes to mind. But for projects that need it this would make SeamELResolver resolution 93% faster. This wouldn't create any backwards compatibility problems because it would be completely optional. But at the same time projects that need to take advantage of it can. I can prepare a patch for this if the idea is approved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues November 2008