May 2011 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-913) SeamApplicationWrapper doesn't implement setApplication() correctly

by Christian Kaltepoth (JIRA)

SeamApplicationWrapper doesn't implement setApplication() correctly ------------------------------------------------------------------- Key: WELD-913 URL: https://issues.jboss.org/browse/WELD-913 Project: Weld Issue Type: Bug Components: Web Tier integration (JSF, JSP, EL and Servlet) Affects Versions: 1.1.0.Final Environment: Tomcat 7.0.8, Seam Faces 3.0.1, MyFaces 2.0.5 Reporter: Christian Kaltepoth While debugging SEAMFACES-165 I discovered that {{SeamApplicationWrapper}} doesn't implement {{setApplication()}} correctly. The class should recreate the locally cached {{Application}} so that future calls to {{getApplication()}} return a correctly wrapped version of the new {{Application}} instance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

3
8
0 / 0

[JBoss JIRA] Created: (WELD-886) AbstractContext creationLock deadlock

by MIchail Nikolaev (JIRA)

AbstractContext creationLock deadlock ------------------------------------- Key: WELD-886 URL: https://issues.jboss.org/browse/WELD-886 Project: Weld Issue Type: Bug Affects Versions: 1.1.1.Final Environment: glassfish Reporter: MIchail Nikolaev AbstractContext.creationLock same for all applications on same server. I have portlet and webservice deployed on same glassfish server. On start of portlet the call to managed bean (@ApplicationScoped) is occured (FolderService.getRootFolder). It causes to lock creationLock in AbstractContext, create instance for bean, then call getRootFolder as default postconstruct method. After getRootFolder calls webservice deployed on the same server. Webservice method access another @ApplicationScoped bean. It causes to lock creationLock again (in another thread) and produces deadlock. Thanks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

4
4
0 / 0

[JBoss JIRA] Created: (WELD-888) Interceptors not resolvable from a WAR-module which is part of an EAR-deployment

by Jan Groth (JIRA)

Interceptors not resolvable from a WAR-module which is part of an EAR-deployment -------------------------------------------------------------------------------- Key: WELD-888 URL: https://issues.jboss.org/browse/WELD-888 Project: Weld Issue Type: Bug Components: Interceptors and Decorators Affects Versions: 1.1.1.Final Environment: - Weld 1.1.1. Final on JBoss 6.0 GA and JBoss 6.1 nightly - tested and confirmed on Vista 32 and Linux 64 Reporter: Jan Groth It seems like CDI interceptors cannot be accessed from inside a WAR-module of an EAR deployment if the interceptor is defined inside a dependent JAR which is located in the EAR/lib directory. BUT: - Managed beans and producers from the same JAR work without problems. - Moving the dependency from EAR/lib to WAR/WEB-INF/lib makes the interceptor work without problems. I consider that a serious problem, because this is a substantial restriction for enterprise applications. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

5
9
0 / 0

[JBoss JIRA] Created: (WELD-851) Upgrade to findbugs-maven-plugin 2.3.2 when available

by Jozef Hartinger (JIRA)

Upgrade to findbugs-maven-plugin 2.3.2 when available ----------------------------------------------------- Key: WELD-851 URL: https://issues.jboss.org/browse/WELD-851 Project: Weld Issue Type: Task Components: Testing Infrastructure (Mocks and Harness Integration) Affects Versions: 1.1.0.Final Reporter: Jozef Hartinger Priority: Minor Upgrade to findbugs-maven-plugin 2.3.2 when available. Due to MFINDBUGS-122 it is not currently possible to run findbugs analysis. http://jira.codehaus.org/browse/MFINDBUGS-122 https://hudson.qa.jboss.com/hudson/view/Weld/job/Weld-trunk-findbugs/399/ -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
4
0 / 0

[JBoss JIRA] Created: (WELD-764) Instance appears to leak memory

by Pete Muir (JIRA)

Instance appears to leak memory ------------------------------- Key: WELD-764 URL: https://jira.jboss.org/browse/WELD-764 Project: Weld Issue Type: Bug Reporter: Pete Muir Fix For: 1.1.0.CR1 Nothing formal to confirm this, just a feeling from looking at a few problems -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (WELD-907) bean-lookup issue in Context#get(Contextual, CreationalContext)

by Gerhard Petracek (JIRA)

bean-lookup issue in Context#get(Contextual, CreationalContext) --------------------------------------------------------------- Key: WELD-907 URL: https://issues.jboss.org/browse/WELD-907 Project: Weld Issue Type: Bug Components: Scopes & Contexts Affects Versions: 1.1.1.Final Reporter: Gerhard Petracek this is a very special case which used to work before weld v1.1.1 e.g.: Set<Bean<?>> beans1 = beanManager.getBeans(MyBean.class); Class beanClass = beans.iterator().next().getBeanClass(); Set<Annotation> qualifiers = beans.iterator().next().getQualifiers(); Set<Bean<?>> beans2 = beanManager.getBeans(beanClass, qualifiers.toArray(new Annotation[qualifiers.size()])); beans1 is the same as beans2 that works without problems. if you use the same in Context#get(Contextual, CreationalContext) it doesn't work. i haven't looked at the details but it might be due to the performance optimizations. the following example isn't that useful (so please don't ask for the reason) - it's just the minimal code to reproduce the issue. public <T> T get(Contextual<T> component, CreationalContext<T> creationalContext) { Class beanClass = ((Bean<T>)component).getBeanClass() Set<Annotation> qualifiers = ((Bean<T>)component).getQualifiers() Set<Bean<?>> beans = CdiUtils.getBeanManager().getBeans(beanClass, qualifiers.toArray(new Annotation[qualifiers.size()])); //beans is empty } it isn't specified that it should work but it used to work with weld and it also works with owb. since there is (imo) no reason why it shouldn't work, it would be great if it gets fixed! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
6
0 / 0

[JBoss JIRA] Created: (WELD-415) testApplicationScopeActiveDuringCallToEjbTimeoutMethod TCK test method is failing in Hudson

by Martin Gencur (JIRA)

testApplicationScopeActiveDuringCallToEjbTimeoutMethod TCK test method is failing in Hudson ------------------------------------------------------------------------------------------- Key: WELD-415 URL: https://jira.jboss.org/jira/browse/WELD-415 Project: Weld Issue Type: Bug Components: Testing Infrastructure (Mocks and Harness Integration) Affects Versions: 1.0.1.CR1 Reporter: Martin Gencur Assignee: Pete Muir Fix For: 1.0.1.CR2 Stack trace: java.lang.AssertionError at org.jboss.jsr299.tck.tests.context.application.ejb.EJBApplicationContextTest.testApplicationScopeActiveDuringCallToEjbTimeoutMethod(EJBApplicationContextTest.java:31) -- 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

12 years, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (WELD-823) Injection into Servlet not working in Jetty 6.x

by Dan Allen (JIRA)

Injection into Servlet not working in Jetty 6.x ----------------------------------------------- Key: WELD-823 URL: https://issues.jboss.org/browse/WELD-823 Project: Weld Issue Type: Bug Components: Web Tier integration (JSF, JSP, EL and Servlet) Affects Versions: 1.1.0.CR4 Reporter: Dan Allen Fix For: 1.1.0.Final Apparently the test suite does not test injection into Servlets for Jetty 6.x because users are reporting that it doesn't work. I added a Servlet injection into the numberguess example and was able to verify that the injection is not taking place, despite receiving the startup message: INFO: Jetty detected, JSR-299 injection will be available in Servlets and Filters. Injection into Listeners is not supported. If this turns out to be a user error, then we need to turn to a documentation improvement, because a guy like Antonio should not be having difficulty getting this to work. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

5
16
0 / 0

[JBoss JIRA] Created: (WELD-915) NPE at org.jboss.weld.util.Beans.mergeInQualifiers(Beans.java:924)

by Ondrej Zizka (JIRA)

NPE at org.jboss.weld.util.Beans.mergeInQualifiers(Beans.java:924) ------------------------------------------------------------------ Key: WELD-915 URL: https://issues.jboss.org/browse/WELD-915 Project: Weld Issue Type: Bug Affects Versions: 1.1.1.Final Environment: Java SE, Sun JDK 1.6 Reporter: Ondrej Zizka Attachments: App.java STR: 1) svn co http://ondrazizka.googlecode.com/svn/trunk/CdiTry or use the attached file 2) Run org.jboss.qa.test.cditry.threads.App.java Exception in thread "main" java.lang.NullPointerException at org.jboss.weld.util.Beans.mergeInQualifiers(Beans.java:924) at org.jboss.weld.bean.builtin.FacadeInjectionPoint.<init>(FacadeInjectionPoint.java:29) at org.jboss.weld.bean.builtin.InstanceImpl.selectInstance(InstanceImpl.java:181) at org.jboss.weld.bean.builtin.InstanceImpl.select(InstanceImpl.java:171) at org.jboss.qa.test.cditry.threads.App.main2(App.java:36) at org.jboss.qa.test.cditry.threads.App.main(App.java:30) PS: I know the usage is completely wrong ;-) I'm just examining Weld. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (WELD-849) Change vendor from sfwk.org to Red Hat for Weld artifacts

by Shane Bryzak (JIRA)

Change vendor from sfwk.org to Red Hat for Weld artifacts --------------------------------------------------------- Key: WELD-849 URL: https://issues.jboss.org/browse/WELD-849 Project: Weld Issue Type: Task Reporter: Shane Bryzak Assignee: Ales Justin I believe this comes from the <organization> tag in the weld-core-parent module. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues May 2011