October 2008 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3383) REST @Context injection for Seam component resources

by Christian Bauer (JIRA)

REST @Context injection for Seam component resources ---------------------------------------------------- Key: JBSEAM-3383 URL: https://jira.jboss.org/jira/browse/JBSEAM-3383 Project: Seam Issue Type: Bug Components: WS Reporter: Christian Bauer Assignee: Christian Bauer Priority: Critical The JAX-RS @Context annotation on fields does not work for JAX-RS resources when the resource class is a Seam component (instantiated and intercepted by Seam). AFAIK the fields annotated with @Context are injected with a proxy when instantiated by Resteasy. When Seam instantiates and manages the object, the proxy isn't injected. Need to find out how Resteasy does that and port it/call it from a Seam interceptor. -- 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

17 years

1
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2589) gen-ui: order of fields in generated forms

by Stephan Grter (JIRA)

gen-ui: order of fields in generated forms ------------------------------------------ Key: JBSEAM-2589 URL: http://jira.jboss.com/jira/browse/JBSEAM-2589 Project: JBoss Seam Issue Type: Feature Request Affects Versions: 2.0.1.GA Environment: Mac OS X 10.4.10 PPC, Java 1.5.0_13-121, JBoss-AS 4.2.2.GA, Seam 2.0.1.GA, PostgreSQL 8.2.4 Reporter: Stephan Grter When I generate the xhtml files from existing entities, then the entry fields will be displayed in alphabetical order of the entity properties and not in the order of declaration. For rapid prototyping it would be desirable, if the fields would appear in the order of declaration. Since the fields in the auto generated database table are in the the order of declaration, this should be possible for gen-ui as well. -- 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

8
12
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2347) ComponentScanner fails with classes in WEB-INF/classes on websphere

by Norman Richards (JIRA)

ComponentScanner fails with classes in WEB-INF/classes on websphere ------------------------------------------------------------------- Key: JBSEAM-2347 URL: http://jira.jboss.com/jira/browse/JBSEAM-2347 Project: JBoss Seam Issue Type: Bug Reporter: Norman Richards Assigned To: Norman Richards Priority: Minor Fix For: 2.0.1.GA If looks like websphere adds the WAR contents directly to the classpath, which causes scanner errors when loading: java.lang.NoClassDefFoundError: WEB-INF.classes.com.somecompany.SomeComponent I'll fix the scanner as soon as I've verified the issue on websphere. -- 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

2
2
0 / 0

[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

17 years

3
15
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

17 years

4
5
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

17 years, 1 month

2
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1840) Serious nasty problem with ManagedEntityIdentityInterceptor

by Przemyslaw Jaskierski (JIRA)

Serious nasty problem with ManagedEntityIdentityInterceptor ----------------------------------------------------------- Key: JBSEAM-1840 URL: http://jira.jboss.com/jira/browse/JBSEAM-1840 Project: JBoss Seam Issue Type: Bug Components: Core Environment: pure Tomcat 6.0.13 + Hibernate 3.2.4, Seam-managed non-JTA Hibernate transactions, Seam.2.CVS.20.08.2007 Reporter: Przemyslaw Jaskierski Priority: Critical First of all, please do not underestimate problem in this report. It's a tough one, and definitely not a malfunction on my side. This disclaimer is because as a developer I know what a PR without a testcase is - but please bear with me. I've already spent ssooo much time on this issue that my co-workers will shoot my head off :(:(:(. I've tried to modify Seam examples to demonstrate it to you, but gave up due to problems with hibernate2 (not working Tomcat deployment), Booking (cannot log into it on AS) (BTW I understand that it's a BETA, just reporting)... It's 100% reproducible in my application, but I'm not allowed to share it :(:(:(. I have a wizard-like, long-running conversation driven by a jpdl pageflow (flushMode=MANUAL). There is a couple of Conversation-scoped Seam components that backs this wizard. I have some @Entity and List<@Entity> fields (pure Hibernate Annotations, no JPA etc.) in some of them. Problem is that ManagedEntityIdentityInterceptor overwrites valid values of these fields with NULL or ArrayList<NULL> values from time to time. It's quite discrete, and I manged to discover this behavior after a huge amount of time only because I've found this: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112335 and http://jira.jboss.com/jira/browse/JBSEAM-1814. Note that in my situation there is no DataModel-related stuff involved, access to these fields is driven by simple get/setters. There is another strange thing. On Seam debug page I enter my conversation scope and list all pojos. There is, for example, "pojoName" and "pojoName.listName" components listed (I have only pojoName component registered with @Name, but looks like it's some kind of Seam optimization). As long as I enter/exit inspection of pojoName component, it's listName preserves its content as expected. But after clicking "pojoName.listName": 1st time it shows it's content, but after entering pojoName and pojoName.listName after this, this list is replaced by [null, null, null etc.] values. No, I don't do anything unusual there, it's a simple plain getter. I think it's not only limited to view-accessed EL-resolved entities, because even my @In components get nullyfied fields (even during the same unit of work, when doing some complex cross-component processing in a single http request). Non-@Entity fields are left untouched. After looking into ManagedEntityIdentityInterceptor code, I changed my fields to TRANSIENT (to be skipped by ignore(Field) method) and this made everything working OK, like expected. Of course having transient fields is not necessary what you want from you pojos, besides I think that it's a serious problem in ManagedEntityIdentityInterceptor that will ruin some nights of other developer if left unresolved. I will gladly test eventual fixes against my codebase. -- 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, 1 month

5
7
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3165) Seam on glassfish 3.1

by Pete Muir (JIRA)

Seam on glassfish 3.1 --------------------- Key: JBSEAM-3165 URL: http://jira.jboss.com/jira/browse/JBSEAM-3165 Project: Seam Issue Type: Task Components: Platform interoperability Reporter: Pete Muir Priority: Critical Fix For: 2.1.0.BETA2 Glassfish 3 is EJB 3.1 based. User reports Seam doesn't work on it. -- 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, 1 month

4
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3079) Building Seam examples should not require internet connection

by Jay Balunas (JIRA)

Building Seam examples should not require internet connection ------------------------------------------------------------- Key: JBSEAM-3079 URL: http://jira.jboss.com/jira/browse/JBSEAM-3079 Project: Seam Issue Type: Task Components: Build, Examples Affects Versions: 2.1.0.A1, 2.0.2.SP1 Reporter: Jay Balunas Assigned To: Jay Balunas Priority: Trivial Fix For: 2.0.3.GA, 2.1.0.BETA1 There are currently two cases: Trinidad for the seamdiscs example el-ri.jar for the hibernate and jpa examples This can be added as optional dependencies and included with the distribution. -- 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, 1 month

2
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1918) Asyncronous methods called from an asyncronously executing methoed will not be invoke asyncronously

by Chris Rudd (JIRA)

Asyncronous methods called from an asyncronously executing methoed will not be invoke asyncronously --------------------------------------------------------------------------------------------------- Key: JBSEAM-1918 URL: http://jira.jboss.com/jira/browse/JBSEAM-1918 Project: JBoss Seam Issue Type: Bug Components: Async Affects Versions: 2.0.0.BETA1 Reporter: Chris Rudd Currently the AsyncronousInterceptor triggers off of Contexts.getEventContext().isSet(AbstractDispatcher.EXECUTING_ASYNCHRONOUS_CALL) to determine if this invocation was from the asyncronous dispatcher. This works fine, except under the conditions where the asyncronously executed method calls another @asyncronous methd. In that case the Event context alreadt contains the AbstractDispatcher.EXECUTING_ASYNCHRONOUS_CALL marked and the execution is done immedialty instead of being scheduled. I belive a simple resolution would be to have the AsyncronousInterceptor clear the AbstractDispatcher.EXECUTING_ASYNCHRONOUS_CALL before proceeding with the exection, but should only be done if the method in question is an @Asycnronous method. This would be to elimiate possible removal from other components that are called during the process of invoking the asyncronous method (ie injection, security, etc). Here is me proposed change : AsyncronousInterceptor.java line 24 @AroundInvoke public Object aroundInvoke(InvocationContext invocation) throws Exception { boolean scheduleAsync = invocation.getMethod().isAnnotationPresent(Asynchronous.class) && !Contexts.getEventContext().isSet(AbstractDispatcher.EXECUTING_ASYNCHRONOUS_CALL); if (scheduleAsync) { Dispatcher dispatcher = AbstractDispatcher.instance(); if (dispatcher==null) { throw new IllegalStateException("org.jboss.seam.async.dispatcher is not installed in components.xml"); } Object timer = dispatcher.scheduleInvocation( invocation, getComponent() ); //if the method returns a Timer, return it to the client return timer!=null && invocation.getMethod().getReturnType().isAssignableFrom( timer.getClass() ) ? timer : null; } + else if( invocation.getMethod().isAnnotationPresent(Asynchronous.class) ) + { + // Clear the async flag so that any async methods called by this invocation will execute asyncronously + Contexts.getEventContext().remove( AbstractDispatcher.EXECUTING_ASYNCHRONOUS_CALL ); + return invocation.proceed(); + } else { return invocation.proceed(); } } -- 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, 1 month

4
6
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues October 2008