March 2009 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3995) example build.xml unexplode targets should use example.ds property

by Jozef Hartinger (JIRA)

example build.xml unexplode targets should use example.ds property ------------------------------------------------------------------ Key: JBSEAM-3995 URL: https://jira.jboss.org/jira/browse/JBSEAM-3995 Project: Seam Issue Type: Bug Components: Examples Affects Versions: 2.1.1.GA Reporter: Jozef Hartinger Priority: Minor Fix For: 2.1.2.CR1 Both unexplode and jbosswar.unexplode targets in examples/build.xml use "${deploy.dir}/${example.name}-ds.xml" to locate datasource file, however ${deploy.dir}/${example.ds} should be used instead. It does not make any difference in most cases, nevertheless some examples (like groovy booking) need to override ${example.ds} property to match real ds file name and this cannot be done if ${example.name}-ds.xml is hardcoded in target. -- 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

16 years

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4000) Allow container-specific deployment properties in functional test framework

by Jozef Hartinger (JIRA)

Allow container-specific deployment properties in functional test framework --------------------------------------------------------------------------- Key: JBSEAM-4000 URL: https://jira.jboss.org/jira/browse/JBSEAM-4000 Project: Seam Issue Type: Task Components: Test Harness Affects Versions: 2.1.1.GA Reporter: Jozef Hartinger Assignee: Jozef Hartinger Priority: Minor Fix For: 2.1.2.CR1 We should be able to specify a set of properties that will be passed to example's build script at deployment. Some examples need this treatment at certain containers (groovybooking at JBoss 5) or configurations (wicket runtime instrumentation) -- 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

16 years

1
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3983) @Observer methods may be called multiple times

by Vanessa Williams (JIRA)

@Observer methods may be called multiple times ---------------------------------------------- Key: JBSEAM-3983 URL: https://jira.jboss.org/jira/browse/JBSEAM-3983 Project: Seam Issue Type: Bug Components: Core Affects Versions: 2.1.1.GA Reporter: Vanessa Williams Some @Observer methods may be called multiple times, while others may not be called at all. This bug is reproducible; occurs in both 2.1.0 and 2.1.1 and requires specific circumstances (described below.) I do not have the time (unfortunately) to create a sample project to demonstrate the problem, but it is easy enough to describe. Create an EntityHome<E> subclass, let's call it FooHome.java. Override the persist() method and at the end of it, raise an event, say "fooSaved". Now, in the same class create a method postFooSaved() and annotate it with @Observer("fooSaved"). In any other component you like, create another @Observer method, with a different name, say watchFoo(), observing the same event. In this case, everything works as expected. After FooHome.persist() is called, postFooSaved() and watchFoo() will each be executed once. Now to replicate the bug: create a subclass of FooHome.java, say BarHome.java. It doesn't matter what it contains. Now postFooSaved() will be executed twice and watchFoo() will not be executed at all. As an extended demonstration, create an action component called FooAction.java and move the original postFooSaved() @Observer to that class. Again, all will work as expected, with postFooSaved() and watchFoo() each executing once. Now create a subclass of FooAction: BarAction.java. The bug will re-appear, with postFooSaved() executing twice and watchFoo() not executing at all. Hope that helps. -- 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

16 years

2
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3993) FacesExpressions incorrectly shares ELContext

by Norman Richards (JIRA)

FacesExpressions incorrectly shares ELContext --------------------------------------------- Key: JBSEAM-3993 URL: https://jira.jboss.org/jira/browse/JBSEAM-3993 Project: Seam Issue Type: Feature Request Affects Versions: 2.1.1.CR2 Reporter: Norman Richards Assignee: Norman Richards -- 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

16 years

1
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3994) Theme component has ELContext reuses issues

by Norman Richards (JIRA)

Theme component has ELContext reuses issues ------------------------------------------- Key: JBSEAM-3994 URL: https://jira.jboss.org/jira/browse/JBSEAM-3994 Project: Seam Issue Type: Feature Request Reporter: Norman Richards Assignee: Norman Richards -- 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

16 years

1
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

16 years

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

16 years

4
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-3265) RESTEasy exception handling

by Christian Bauer (JIRA)

[ https://jira.jboss.org/jira/browse/JBSEAM-3265?page=com.atlassian.jira.pl... ] Christian Bauer commented on JBSEAM-3265: ----------------------------------------- Discussion thread on RE mailing list: http://sourceforge.net/mailarchive/forum.php?thread_name=574A6C63-D67A-44... > RESTEasy exception handling > --------------------------- > > Key: JBSEAM-3265 > URL: https://jira.jboss.org/jira/browse/JBSEAM-3265 > Project: Seam > Issue Type: Task > Components: WS > Reporter: Christian Bauer > Assignee: Christian Bauer > > JAX-RS specifies the ExceptionMapper providers: The job of an ExceptionMapper is to convert an Exception instance to an HttpResponse. > Two issues with that: > RESTEasy does all that internally, that means once we dispatch a request to RESTEasy, we'll never get an exception out of the dispatcher call, only an HttpResponse. So we can't do internal cleanup of Seam contexts after an exception occurs. > Second problem is that Seam has exactly the same functionality built-in, with ExceptionHandler and pages.xml declarations of mappings. So we definitely should give users the option to use that instead of writing a dozen ExceptionMapper classes. To get this working we need to get the exception out of the dispatcher invocation, to either call RESTEasy ExceptionMappers from outside of the dispatcher or to let it bubble up to the Seam ExceptionHandler so pages.xml can be used. > This requires a rewrite of the exception handling in RESTEasy, the issue has been brought up on their dev mailing list. -- 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

16 years

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3986) EJB Warning Request with Bijection

by Shawn Gunsolley (JIRA)

EJB Warning Request with Bijection ---------------------------------- Key: JBSEAM-3986 URL: https://jira.jboss.org/jira/browse/JBSEAM-3986 Project: Seam Issue Type: Feature Request Components: Core, EJB3 Affects Versions: 2.1.1.GA Environment: EJB3 used in a Seam application Reporter: Shawn Gunsolley This request is for a compile warning when an EJB has member variables with Bijection or Factory methods. The issue can cause a problem where users were passed incorrect information via stateless beans. The following is an example: @Stateless @Name("accountStuff") public class AccountStuffBean { @In(create=true) @Out private User user; @Factory("user") public void createUser(){ //error occurs in User B } } @Name("user") @Scope(SESSION) public class User implements Serializable{ } Here is the scenario that this goes south: • User A - request the stateless bean and creates the user information o This creates the local variable in the stateless bean for a user o This stores a reference to that variable in the Session of User A o Finally the stateless bean is returned to the container • Now there is two places the variable is present the JEE container and the User A Session • Due to JEE specs there is no requirement to clear the container beans member variables (And JBoss does not clear this member variable) • User B - hits the same portion of the code and is returned the Stateless bean that User A returned to the container o Seam checks if the variable is in the Session (it is not because this is not User A) o Seam checks to see if it should be created (it shouldn't because it exists) o ***User B is returned User A's variable for user**** This truly is a coding error that is why this is an enhancement request. The developer should not assume that the member variable clears in a stateless bean. -- 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

16 years

1
1
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

16 years

2
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues March 2009