June 2011 - weld-issues - Jboss List Archives

[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

13 years, 7 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

13 years, 7 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

13 years, 7 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

13 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (WELD-922) Build of Weld core fails with "Could not find artifact javax.servlet:jstl:jar:1.2"

by Marek Schmidt (JIRA)

Build of Weld core fails with "Could not find artifact javax.servlet:jstl:jar:1.2" ---------------------------------------------------------------------------------- Key: WELD-922 URL: https://issues.jboss.org/browse/WELD-922 Project: Weld Issue Type: Bug Components: Infrastructure Affects Versions: 1.1.1.Final Reporter: Marek Schmidt Building weld with "mvn package" fails with {quote} [ERROR] Failed to execute goal on project weld-servlet-test-tomcat: Could not resolve dependencies for project org.jboss.weld.servlet:weld-servlet-test-tomcat:jar:1.1.0-SNAPSHOT: Could not find artifact javax.servlet:jstl:jar:1.2 in jboss-public-repository-group (http://repository.jboss.org/nexus/content/groups/public) -> [Help 1] {quote} It appears that javax.servlet:jstl:jar:1.2, which is declared in api/bom/pom.xml and used in Weld tests and examples, has been removed from central (see https://issues.sonatype.org/browse/MVNCENTRAL-71 ) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

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

13 years, 8 months

3
6
0 / 0

[JBoss JIRA] Assigned: (WELD-924) Weld not checking for null keys on bean lookups

by Ales Justin (JIRA)

[ https://issues.jboss.org/browse/WELD-924?page=com.atlassian.jira.plugin.s... ] Ales Justin reassigned WELD-924: -------------------------------- Assignee: Stuart Douglas > Weld not checking for null keys on bean lookups > ----------------------------------------------- > > Key: WELD-924 > URL: https://issues.jboss.org/browse/WELD-924 > Project: Weld > Issue Type: Bug > Components: Resolution (Typesafe and by Name) > Environment: Beta4-SNAPSHOT > Reporter: Lincoln Baxter III > Assignee: Stuart Douglas > > https://github.com/LightGuard/seam-example-confbuzz > Attempt to build and deploy the above sample application to any recent AS7 instance. Weld fails to boot with a NullPointerException. > {code} > 11:05:06,820 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.deployment.unit."confbuzz-1.0.0-SNAPSHOT.war".component.EjbSynchronizationsDelegate.WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."confbuzz-1.0.0-SNAPSHOT.war".component.EjbSynchronizationsDelegate.WeldInstantiator: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1736) > at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2302) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24] > at java.lang.Thread.run(Thread.java:680) [:1.6.0_24] > Caused by: java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) [:1.6.0_24] > at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:1209) > at org.jboss.as.weld.injection.WeldManagedReferenceFactory.start(WeldManagedReferenceFactory.java:119) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1715) > ... 4 more{code} > I believe this is a potential bug in the Weld integration, or maybe in Weld itself, but this just shows up on AS7, so not really sure. Starting here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

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

13 years, 8 months

3
5
0 / 0

[JBoss JIRA] Created: (CDITCK-218) Assumption all @Stateful beans should be passivation capable

by David Blevins (JIRA)

Assumption all @Stateful beans should be passivation capable ------------------------------------------------------------ Key: CDITCK-218 URL: https://issues.jboss.org/browse/CDITCK-218 Project: CDI TCK Issue Type: CTS Challenge Security Level: Public (Everyone can see) Reporter: David Blevins Stateful session beans in transactions can't be passivated and shouldn't have passivation requirements either, like request scope. Stateful beans can be any scope. They are the Bertie Bott's Every Flavor Beans of EJB. It's too big of a brush to say that passivation is always required. That's the part we need to fix. Stateful session beans that do passivate are pretty rare. They should be assumed to be @NormalScope unless otherwise specified. The user should be able to say if they want passivation validation on their stateful bean and dependencies. We should at a minimum change the related language of the spec to be "For every bean which declares a passivating scope, and for every stateful session bean ***that requires passivation***, " and discuss how to determine that an SFSB requires passivation. >From the EJB perspective this has always been a container detail, but we could have a rule in CDI that states the checks are not enforced unless the bean class explicitly implements java.io.Serializable. Alternatively we could make a generic @PassivationScoped annotation for other architectures that have flexible scopes and support passivation concepts. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (CDITCK-215) ProcessSessionBeanTest testProcessSessionBeanEvent count

by David Blevins (JIRA)

ProcessSessionBeanTest testProcessSessionBeanEvent count -------------------------------------------------------- Key: CDITCK-215 URL: https://issues.jboss.org/browse/CDITCK-215 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.0.4.Final Reporter: David Blevins [Side note maybe there should be versions for 1.0.4.SP1 and 1.0.4.SP2] Test: org.jboss.jsr299.tck.tests.extensions.processBean.ProcessSessionBeanTest.testProcessSessionBeanEvent Not sure if this is an issue or not, so filling this as a bug and not a challenge. The test essentially has two observer methods and is asserting that only one of them are called. public void observeElephantSessionBean(@Observes ProcessSessionBean<Elephant> event) { ProcessBeanObserver.elephantProcessSessionBean = event; } public void observeElephantBean(@Observes ProcessBean<Elephant> event) { ProcessBeanObserver.elephantProcessBeanCount++; } Specifically the test asserts that observeElephantSessionBean is called and that observeElephantBean is not called. Currently we call both because ProcessSessionBean is assignable to ProcessBean and the generics are the same. Is there a part of the spec that mandates only the most specific observer method is called? The only thing I can find is in 10.4 which says pretty clearly: There may be arbitrarily many observer methods with the same event parameter type and qualifiers. A bean (or extension) may declare multiple observer methods. Well I guess it's not that clear as it says essentially "this may happen" rather than "this may happen...and when it does the behavior is...[all are invoked || only the most specific is invoked]" -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

3
10
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues June 2011