weld-issues December 2010

weld-issues@lists.jboss.org

1 participants
265 discussions

[JBoss JIRA] Updated: (WELD-80) Passivation of stateful session beans results in a loss of reference to injected object

by Pete Muir (JIRA)

[ https://jira.jboss.org/browse/WELD-80?page=com.atlassian.jira.plugin.syst... ] Pete Muir updated WELD-80: -------------------------- Fix Version/s: TBC (was: 1.1.0.CR1) Needs fixes in JBoss EJB 3 to test. Fixes are not guaranteed for AS 6 so slipping to TBC for clarity. > Passivation of stateful session beans results in a loss of reference to injected object > --------------------------------------------------------------------------------------- > > Key: WELD-80 > URL: https://jira.jboss.org/browse/WELD-80 > Project: Weld > Issue Type: Bug > Components: Scopes & Contexts > Environment: JBoss AS 5.1 > Reporter: John Ament > Fix For: TBC > > Attachments: statefulpassivate.zip > > > See forum post -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (WELD-59) Clustered WebBeans, no support for sessionscoped (and higher) replication

by Pete Muir (JIRA)

[ https://jira.jboss.org/browse/WELD-59?page=com.atlassian.jira.plugin.syst... ] Pete Muir updated WELD-59: -------------------------- Fix Version/s: TBC (was: 1.1.0.CR1) Issues in JBoss EJB 3 mean that we can't test Weld in a cluster. We are aiming to get these EJB3 issues resolved for AS 6, but that is not certain (I have pleaded ;-). So slipping this to TBC for clarity. > Clustered WebBeans, no support for sessionscoped (and higher) replication > ------------------------------------------------------------------------- > > Key: WELD-59 > URL: https://jira.jboss.org/browse/WELD-59 > Project: Weld > Issue Type: Bug > Components: Scopes & Contexts > Affects Versions: 1.0.0.PREVIEW1 > Environment: JBoss AS 5.1 + JDK 6 > Reporter: John Ament > Fix For: TBC > > Attachments: ClusteredWebBeansTestApp.zip, ClusteredWebBeansTestApp.zip > > > From what I can tell, this is what happens. > Assume you have a 2 node environment w/ apache httpd + mod_jk in front of the jboss servers, used to limit servers exposed + a loadbalancer (F5 ASM) in front of those. The apache servers are only configured to talk to one jboss server each (httpd + jboss are on same box, they only talk to the local client). the f5 serving the initial request is configured for pure round robin (no cookie persistence) and as a result request 1 could go to server 1 and then request 2 goes to server 2. > Now assume that the two jboss servers are clustered together, the EJBs are clustered and have a cache policy (based on the JBoss annotations). They only have local interfaces. In addition, there are some classes that are only POJOs; but they sit in the ejb module. Based on what's happening these objects should be replicated as part of the HTTP session state. > A few problems seem to occur when the request goes to the second server after the first request goes to the first server. > 1. References to the resources required by the EJBs are not injected in the second server. This includes members decorated @Resource or @PersistenceContext > 2. References to EJBs required at the view level are not restored. > In addition, concurrent modification exceptions seem to be more likely when deployed like this, resulting in having to downgrade EJBs to POJOs in order to remain stateful. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (WELD-759) Exceptions might leave locked conversations

by Nicklas Karlsson (JIRA)

Exceptions might leave locked conversations ------------------------------------------- Key: WELD-759 URL: https://jira.jboss.org/browse/WELD-759 Project: Weld Issue Type: Bug Components: Conversations Affects Versions: 1.1.0.Beta2 Reporter: Nicklas Karlsson Because conversations are not unlocked in a finally-block exceptions might cause the JSF lifecycle to be exited before the conversation has been unlocked which will lead to failure in acquiring the conversation lock when the user refreshes the browser or otherwise retries the operation. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
7
0 / 0

[JBoss JIRA] Assigned: (WELD-91) Document a strategy for writing a unit test which guards against performance blackspots reoccurring

by Pete Muir (JIRA)

[ https://jira.jboss.org/browse/WELD-91?page=com.atlassian.jira.plugin.syst... ] Pete Muir reassigned WELD-91: ----------------------------- Assignee: Martin Gencur Martin, I think this is largely done with our Hudson runs. Only thing they don't have is a monitor, checking for things getting worse. Is there some way to add that in? Make sure we don't get regressions? > Document a strategy for writing a unit test which guards against performance blackspots reoccurring > --------------------------------------------------------------------------------------------------- > > Key: WELD-91 > URL: https://jira.jboss.org/browse/WELD-91 > Project: Weld > Issue Type: Task > Components: Testing Infrastructure (Mocks and Harness Integration) > Reporter: Pete Muir > Assignee: Martin Gencur > Fix For: 1.1.0.CR1 > > > When someone reports/isolates a performance issue, we need to write a unit test to stop it reoccurring (a regression occurring). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (WELD-712) Regression in Extension proxy method invocations

by Sivakumar Thyagarajan (JIRA)

Regression in Extension proxy method invocations ------------------------------------------------ Key: WELD-712 URL: https://jira.jboss.org/browse/WELD-712 Project: Weld Issue Type: Bug Components: Proxies, Reflection layer Affects Versions: 1.1.0.Beta1 Environment: Latest GlassFish that has 1.1.0-01-glassfish build of Weld integrated. To reproduce the problem the following system property needs to be set to bypass the Jersey workaround for this issue. <jvm-options>-Dcom.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true</jvm-options> Reporter: Sivakumar Thyagarajan Fix For: 1.1.0.Beta2 Glassfish issue 13131 [1], involving the Jersey portable extension, notes that there has been a regression in the last integration of Weld (1.1.0-01-glassfish). It appears that invocations on observer methods of container lifecycle events are handled in the proxy and delegated to the proxied instance of the Extension, whereas invocations of non-observer methods on a Extension that is obtained from BeanManager, are directed towards the non-proxied instance of the Extension. This behaviour appears to have been changed after Weld 1.0 More details: The Jersey extension has a private initialization method (initialize() [2]) that inits the state of the extension during beforeBeanDiscovery. I notice that there are two instances of the Extension being created (because the extension is being proxied) -- let us call it actual_instance1 and proxy_instance_2. beforeBeanDiscovery observer method is called on proxy_instance_2 and this method call in turn delegates to actual_instance1 and initialize() method is called on actual_instance1. So now actual_instance1's state is initialized correctly. However later when the Extension is looked up through the BeanManager elsewhere [3], the proxy_instance_2 is returned. When a non-observer method (lateInitialize [4]) is called on this instance proxy_instance_2, this method call goes to proxy_instance_2 and is not forwarded to actual_instance_1. Since the state is not initialized in proxy_instance_2, this call fails. Please see the attached text file for stack traces related to the various stages discussed above and also contact me should you need to reproduce this. [1] http://glassfish.dev.java.net/issues/show_bug.cgi?id=13131 [2] intialize method in https://jersey.dev.java.net/svn/jersey/trunk/jersey/jersey-server/src/mai... [3] constructor in CDIComponentProviderFactory looks up the Extension using the BeanManager https://jersey.dev.java.net/svn/jersey/trunk/jersey/jersey-server/src/mai... [4] lateInitialize in https://jersey.dev.java.net/svn/jersey/trunk/jersey/jersey-server/src/mai... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
10
0 / 0

← Newer
1
...
24
25
26
27
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues December 2010