February 2009 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3645) Support co-existence of multiple view layers in same deployment

by Clint Popetz (JIRA)

Support co-existence of multiple view layers in same deployment --------------------------------------------------------------- Key: JBSEAM-3645 URL: https://jira.jboss.org/jira/browse/JBSEAM-3645 Project: Seam Issue Type: Patch Reporter: Clint Popetz Attachments: multi-view.diff Currently one must choose between wicket and jsf when using seam, because the wicket support works by overriding certain faces components. This patch eliminates that limitation. This patch should be applied after the patches from the issues linked to this issue, which are also related to wicket development. There are four parts of this patch. (1) The Manager and StatusMessages components are currently implemented in jsf with FacesManager and FacesMessages, and in wicket with WicketManager and WicketStatusMessages. Since a mixed deployment would need all managers to be @Installed, this patch makes each have a separate @Name, and makes the base classes (Manager and StatusMessages) @Unwrap themselves as one of the subclass components. Each subclass component registers itself with the base class component (by observing the postInitialization event) as a possible implementation. When Manager.instance() or StatusMessages.instance() is invoked, and the base component is created, @Unwrap is called, and that method asks each subclass component whether they should be used for that event scope. The Wicket implementations say yes if the wicket Application.exists() (which uses a ThreadLocal) returns true. The Faces implementations says yes if facesContext is not null. This patch assumes that both will not simultaneously return true, and if so, the behavior is undefined, as it's first-come-first-serve. If neither return true, the default Manager and StatusMessages implementation will be used. This happens during initialization and other edge cases where a manager is needed for event contexts that aren't tied to real requests. Note that since the FacesMessages component no longer has the same @Name as the StatusMessages component, it is now "org.jboss.seam.faces.facesMessages" which means the two factories for that name and its unqualified form in jboss-seam.jar's components.xml have been removed. (2) Seam's WicketFilter currently sets up scopes unconditionally if it is installed. This causes faces requests to fail because the SeamPhaseListener also sets up and tears down scopes, and so when the wicket filter finishes and tries to tear down its scopes, it finds them gone and an exception occurs. I've changed WicketFilter to not set up scopes, but instead to have WicketFilterInstantiator's anonymous subclass of the real WicketFilter install the scopes _if_ wicket has determined the request is a wicket request. (3) WicketExceptionFilter existed only to turn off the base ExceptionFilter for wicket classes. I've removed this class, and we'll need to add to the wicket seam documentation the need to map the ExceptionFilter in components.xml to jsf paths if wicket is to be used alongside jsf. (4) WicketRedirectFilter now co-exists with the base RedirectFilter, rather than replacing it. It checks to see if Wicket is active (via the same Application.exists() call as above) before doing any work to redirects, so that it doesn't duplicate work that the jsf RedirectFilter does. Likewise, The jsf RedirectFilter now checks to see if there is a faces context before doing any work. -- 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, 9 months

3
15
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3868) Automate seam-gen testing from the release-process.txt

by Jay Balunas (JIRA)

Automate seam-gen testing from the release-process.txt ------------------------------------------------------- Key: JBSEAM-3868 URL: https://jira.jboss.org/jira/browse/JBSEAM-3868 Project: Seam Issue Type: Task Components: Test Harness Affects Versions: 2.1.1.GA Reporter: Jay Balunas Assignee: Jay Balunas Priority: Critical Fix For: The future The release testing process outlined in release-process.txt for seam-gen needs to be automated. This will be a mixture of ant, selenium, etc.... -- 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, 9 months

2
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3885) Make CookiePath for RememberMe cookies optionally fixed

by Klaasjan te Voortwis (JIRA)

Make CookiePath for RememberMe cookies optionally fixed ------------------------------------------------------- Key: JBSEAM-3885 URL: https://jira.jboss.org/jira/browse/JBSEAM-3885 Project: Seam Issue Type: Feature Request Components: Security Affects Versions: 2.1.1.GA Reporter: Klaasjan te Voortwis The RememberMe cookies are stored on the same path as where the page was served from. When providing a user/pass field in the top of all pages, a user can for example - log in on http://domain.name/issuesystem/issue/create.seam, and mark RememberMe true - come back to the site http://domain.name/someotherpath, and now the user is not logged in (optionally) fixing the CookiePath for the RememberMe cookies to "/" instead of ctx.getExternalContext().getRequestContextPath() will solve this issue. Setting the cookiePath is done in RememberMe.java on lines 221 and 238. -- 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, 9 months

3
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3965) @Providers not working - ResteasyDispatcher registers components and providers in wrong order

by Balazs Pataki (JIRA)

@Providers not working - ResteasyDispatcher registers components and providers in wrong order --------------------------------------------------------------------------------------------- Key: JBSEAM-3965 URL: https://jira.jboss.org/jira/browse/JBSEAM-3965 Project: Seam Issue Type: Bug Components: WS Affects Versions: 2.1.1.CR1 Reporter: Balazs Pataki While using the latest nightly build (from 2009.02.19) I found that my @Provider annotated class is not used by Seam+RESTEasy. It seemed to be loaded but not used by injection mechanism. By debugging the code I found out that it is not used because org.jboss.seam.resteasy.ResteasyDispatcher#onStartup() first registers the resources and after that the providers. However, as part of the resource registration the injection mechanism including the converters are set up, however at this point the converters (providers) have not been loaded. It seems to first load the providers and then the resources. This is my patch that worked in my setup: > diff -c ResteasyDispatcher.java ResteasyDispatcher_orig.java *** ResteasyDispatcher.java 2009-02-20 11:10:35.000000000 +0100 --- ResteasyDispatcher_orig.java 2009-02-19 00:18:26.000000000 +0100 *************** *** 56,91 **** getDispatcher().setLanguageMappings(application.getLanguageMappings()); getDispatcher().setMediaTypeMappings(application.getMediaTypeMappings()); - // Provider registration - if (application.isUseBuiltinProviders()) - { - log.info("registering built-in RESTEasy providers"); - RegisterBuiltin.register(providerFactory); - } - for (Class providerClass : application.getProviderClasses()) - { - Component seamComponent = application.getProviderClassComponent(providerClass); - if (seamComponent != null) - { - if (ScopeType.STATELESS.equals(seamComponent.getScope())) - { - throw new RuntimeException( - "Registration of STATELESS Seam components as RESTEasy providers not implemented!" - ); - } - else if (ScopeType.APPLICATION.equals(seamComponent.getScope())) - { - Object providerInstance = Component.getInstance(seamComponent.getName()); - providerFactory.registerProviderInstance(providerInstance); - } - } - else - { - // Just plain RESTEasy, no Seam component lookup or lifecycle - providerFactory.registerProvider(providerClass); - } - } - // Resource registration Registry registry = getDispatcher().getRegistry(); for (final Class resourceClass : application.getClasses()) --- 56,61 ---- *************** *** 133,137 **** --- 103,138 ---- registry.addResourceFactory(new POJOResourceFactory(resourceClass)); } } + + // Provider registration + if (application.isUseBuiltinProviders()) + { + log.info("registering built-in RESTEasy providers"); + RegisterBuiltin.register(providerFactory); + } + for (Class providerClass : application.getProviderClasses()) + { + Component seamComponent = application.getProviderClassComponent(providerClass); + if (seamComponent != null) + { + if (ScopeType.STATELESS.equals(seamComponent.getScope())) + { + throw new RuntimeException( + "Registration of STATELESS Seam components as RESTEasy providers not implemented!" + ); + } + else if (ScopeType.APPLICATION.equals(seamComponent.getScope())) + { + Object providerInstance = Component.getInstance(seamComponent.getName()); + providerFactory.registerProviderInstance(providerInstance); + } + } + else + { + // Just plain RESTEasy, no Seam component lookup or lifecycle + providerFactory.registerProvider(providerClass); + } + } + } } -- 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, 9 months

3
8
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3452) resteasy-2.1.xsd fails eclipse xsd validation

by Scott Olcott (JIRA)

resteasy-2.1.xsd fails eclipse xsd validation --------------------------------------------- Key: JBSEAM-3452 URL: https://jira.jboss.org/jira/browse/JBSEAM-3452 Project: Seam Issue Type: Bug Components: WS Affects Versions: 2.1.0.BETA1 Reporter: Scott Olcott -- 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, 9 months

4
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3690) Add functional tests for Seam examples

by Jozef Hartinger (JIRA)

Add functional tests for Seam examples -------------------------------------- Key: JBSEAM-3690 URL: https://jira.jboss.org/jira/browse/JBSEAM-3690 Project: Seam Issue Type: Task Components: Examples, Test Harness Reporter: Jozef Hartinger Assignee: Jozef Hartinger -- 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, 9 months

1
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3932) org.jboss.el.util.ReflectionUtil/org.jboss.el.util.ReferenceCache causes thread and memory leak

by Alexander Schwartz (JIRA)

org.jboss.el.util.ReflectionUtil/org.jboss.el.util.ReferenceCache causes thread and memory leak ----------------------------------------------------------------------------------------------- Key: JBSEAM-3932 URL: https://jira.jboss.org/jira/browse/JBSEAM-3932 Project: Seam Issue Type: Bug Affects Versions: 2.1.1.GA Environment: Tomcat w/ Seam on Windows Reporter: Alexander Schwartz org.jboss.el.util.ReflectionUtil (from jboss-el) uses a private static ReferenceCache methodCache and this ReferenceCache is leaking a thread that is used for cleanup. You can't call a cleanup method from the outside. But the methodCache could be removed from the code as it is not used anyway: it is read in findMethod(), but nothing is stored (the code is commented out in version 1.0_02.CR2, and not present in all other souces (2.0.2.CR1, 2.0.1.GA). Every redeployment of an application will leak one thread due to this bug. And it causes a memory leak as the web application class loader can't be unloaded due to this bug. The pom.xml of jboss-el states "JBoss EL is a extended EL implementation, distributed with Seam", therefore I report this bug against Seam. -- 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, 9 months

3
10
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3181) Add conversation management metadata to Wicket component model

by Pete Muir (JIRA)

Add conversation management metadata to Wicket component model -------------------------------------------------------------- Key: JBSEAM-3181 URL: https://jira.jboss.org/jira/browse/JBSEAM-3181 Project: Seam Issue Type: Task Reporter: Pete Muir -- 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, 9 months

2
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3724) Wicket NoConversationPage is often ignored

by Clint Popetz (JIRA)

Wicket NoConversationPage is often ignored ------------------------------------------ Key: JBSEAM-3724 URL: https://jira.jboss.org/jira/browse/JBSEAM-3724 Project: Seam Issue Type: Bug Components: Wicket Reporter: Clint Popetz Assignee: Clint Popetz The SeamComponentInstantiationListener will only be invoked when a page/component is first created, which is not the case when back-buttoning into a form that you already submitted, for example. So we're able to back-button into dead conversations. To make sure NoConversationPage is respected we do one of the following: (a) throw the AbortException() in the ConversationInterceptor (b) make user pages derive from a SeamWebPage, and override onPageAttached() to check for the annotation/conversation (c) when instrumenting, if a component is a page subclass, add a synthetic onPageAttached() to do (b) if it doesn't exist, or supplement any existing one. I prefer (a) because it means a seam-instrumented wicket component will never be called outside a long running conversation if NoConversationId is set, regardless of how the wicket request cycle api changes. Pete, any thoughts? -- 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, 9 months

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3980) Move Seam session subclass to its own top level class

by Clint Popetz (JIRA)

Move Seam session subclass to its own top level class ----------------------------------------------------- Key: JBSEAM-3980 URL: https://jira.jboss.org/jira/browse/JBSEAM-3980 Project: Seam Issue Type: Bug Components: Wicket Affects Versions: 2.1.1.GA Reporter: Clint Popetz Assignee: Clint Popetz Priority: Minor So that it can be subclassed by users. -- 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, 9 months

1
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues February 2009