November 2011 - weld-issues - Jboss List Archives

[JBoss JIRA] (WELD-912) Specializing beans in different bean archives does not work

by Fabricio Lemos (Commented) (JIRA)

[ https://issues.jboss.org/browse/WELD-912?page=com.atlassian.jira.plugin.s... ] Fabricio Lemos commented on WELD-912: ------------------------------------- I´m also having problems with plain @Alternative (without @Specializes). The @Alternative bean does not replace the original bean if the original bean is in an JAR. I agree it is a really serious bug, which prevents the implementation of modular dependencies (http://relation.to/Bloggers/ModularDependencies) which IMO is the most important use case for Alternatives. > Specializing beans in different bean archives does not work > ----------------------------------------------------------- > > Key: WELD-912 > URL: https://issues.jboss.org/browse/WELD-912 > Project: Weld > Issue Type: Bug > Components: Bootstrap and Metamodel API > Affects Versions: 1.1.1.Final > Reporter: Nicklas Karlsson > Fix For: 1.2.0.Beta1 > > Attachments: test.zip > > > @Specializing a bean that is deployed in a different bean archive fails with the following exception: > Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000047 Specializing bean must extend another bean: Managed Bean [class fi.affecto.test.MyApplicationBundles] with qualifiers [@Any @Default] > at org.jboss.weld.bean.ManagedBean.specialize(ManagedBean.java:545) > at org.jboss.weld.bean.AbstractBean.initialize(AbstractBean.java:124) > at org.jboss.weld.bean.AbstractClassBean.initialize(AbstractClassBean.java:202) > at org.jboss.weld.bean.ManagedBean.initialize(ManagedBean.java:372) > at org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy(AbstractBeanDeployer.java:113) > at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:216) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:370) > at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) > at org.jboss.as.weld.services.WeldService.start(WeldService.java:89) > ... 4 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (WELD-358) InjectionPoint parameter on disposer method is null

by David Allen (JIRA)

InjectionPoint parameter on disposer method is null --------------------------------------------------- Key: WELD-358 URL: https://jira.jboss.org/jira/browse/WELD-358 Project: Weld Issue Type: Bug Components: Producers (Methods, Fields and Disposers) Affects Versions: 1.0.0.GA Reporter: David Allen Adding a parameter of type InjectionPoint on a disposer method should inject the corresponding meta-data for the place where the bean had been injected; for the bean being destroyed. See http://www.seamframework.org/Community/DisposingAndInjectionPointIntegrat... and the Weld test org.jboss.weld.tests.producer.method.DisposalMethodInjectionPointTest. -- 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, 2 months

4
7
0 / 0

[JBoss JIRA] (WELD-892) Calling session-scoped components from session initialized observer goes into infinite loop

by Ales Justin (Updated) (JIRA)

[ https://issues.jboss.org/browse/WELD-892?page=com.atlassian.jira.plugin.s... ] Ales Justin updated WELD-892: ----------------------------- Assignee: Ales Justin (was: Marko Strukelj) Workaround Description: (was: Use a flag and a request-scoped observer class {code} @RequestScoped public class Observer { @Inject Pinger pinger; private boolean handling; public void newSession(@Observes @Initialized HttpSession s) { if (!handling) { handling = true; pinger.ping(); } } } {code}) > Calling session-scoped components from session initialized observer goes into infinite loop > ------------------------------------------------------------------------------------------- > > Key: WELD-892 > URL: https://issues.jboss.org/browse/WELD-892 > Project: Weld > Issue Type: Bug > Components: Scopes & Contexts > Affects Versions: 1.1.1.Final > Reporter: Nicklas Karlsson > Assignee: Ales Justin > > Given a session scoped component > {code} > @SessionScoped > public class Pinger implements Serializable > { > public void ping() > { > }; > } > {code} > and a session initialized observer calling it > {code} > public class Observer > { > @Inject > Pinger pinger; > public void newSession(@Observes @Initialized HttpSession s) > { > pinger.ping(); > } > } > {code} > We go off into an infinite loop. Since Pinger doesn't exist, it is created and placed in the session scoped beanstore, which creates a session and fires off the observer. I'm not sure why the session isn't considered created at this point. This is bordering on feature since I think the result would be the same if servlet listeners would be used. Perhaps this could be worked around int the event bridge somehow so that the firing would be prevented if we're already handling the session created event... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WELD-1002) Interceptor/Decorator injection point validation logic incorrect

by Jozef Hartinger (Created) (JIRA)

Interceptor/Decorator injection point validation logic incorrect ---------------------------------------------------------------- Key: WELD-1002 URL: https://issues.jboss.org/browse/WELD-1002 Project: Weld Issue Type: Bug Components: Interceptors and Decorators Affects Versions: 1.1.2.Final Reporter: Jozef Hartinger Assignee: Jozef Hartinger Fix For: 1.2.0.Beta1, 2.0.0.Alpha1 {code:JAVA} for (InjectionPoint injectionPoint : serializableContextual.get().getInjectionPoints()) { Bean<?> resolvedBean = beanManager.resolve(beanManager.getBeans(injectionPoint)); validateInjectionPoint(injectionPoint, beanManager); if (classBean.isPassivationCapableBean()) { validateInjectionPointPassivationCapable(injectionPoint, resolvedBean, beanManager); } } {code} *classBean.isPassivationCapableBean()* checks if the intercepted bean is passivation capable. However, even if the interceptor bean is passivation capable, the interceptor is not obliged to have passivation capable dependencies unless the intercepted bean declares a *passivating scope*. The condition (note there are multiple occurences) should be based on this check instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

5
5
0 / 0

[JBoss JIRA] Created: (WELD-374) Provide sane toString() for classes

by Pete Muir (JIRA)

Provide sane toString() for classes ----------------------------------- Key: WELD-374 URL: https://jira.jboss.org/jira/browse/WELD-374 Project: Weld Issue Type: Feature Request Reporter: Pete Muir Priority: Critical Fix For: 1.0.1.CR1 Currently these vary in quality, some providing good info (e.g. WeldClassImpl), some too little (e.g. WeldFieldImpl) and some are just crazy. In general, the approach should be to delegate the toString to the Names class (see toString(Class<?> rawType, Set<Annotation> annotations, Type[] actualTypeArguments) for a good one). -- 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, 2 months

4
11
0 / 0

[JBoss JIRA] (WELD-1010) @PreDestroy method invoked twice

by wojtek k (Created) (JIRA)

@PreDestroy method invoked twice -------------------------------- Key: WELD-1010 URL: https://issues.jboss.org/browse/WELD-1010 Project: Weld Issue Type: Bug Components: Scopes & Contexts Affects Versions: 1.1.3.SP1 Environment: All Reporter: wojtek k Fix For: 1.2.0.Beta1 @PreDestroy method on @Dependend scope is invoked twice when we use Bean.destroy() method. Problem occurs in destroy() method: getInjectionTarget().preDestroy(instance); creationalContext.release(); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

5
5
0 / 0

[JBoss JIRA] Created: (WELD-617) Can not find beans when deploying compressed Archive to Tomcat

by Aslak Knutsen (JIRA)

Can not find beans when deploying compressed Archive to Tomcat -------------------------------------------------------------- Key: WELD-617 URL: https://jira.jboss.org/browse/WELD-617 Project: Weld Issue Type: Bug Components: Servlet Container Support Affects Versions: 1.0.1.Final Reporter: Aslak Knutsen When deploying a compressed Archive on Tomcat, WebAppBeanDeploymentArchive.scan fails to find and classes. In WebAppBeanDeploymentArchive.scan we try to get the File object representation of the WEB-INF/classes directory so we can recursively scan for classes, but in Tomcat this is a URL to jndi backed by a DirContext. WebAppBeanDeploymentArchive.scan { // inside scan File webInfClasses = Servlets.getRealFile(servletContext, WEB_INF_CLASSES); { // inside getRealFile String realPath = servletContext.getRealPath(path); realPath == null URL resourcePath = servletContext.getResource(path); resourcePath == jndi:/localhost/test/WEB-INF/classes } webInfClasses == null } End result is no classes are found. -- 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, 2 months

5
9
0 / 0

[JBoss JIRA] Created: (WELD-904) Observer method inheritance broken

by Christian Bauer (JIRA)

Observer method inheritance broken ---------------------------------- Key: WELD-904 URL: https://issues.jboss.org/browse/WELD-904 Project: Weld Issue Type: Bug Affects Versions: 1.1.1.Final Reporter: Christian Bauer Priority: Minor /* <beans xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd"> <alternatives> <class>Foo$Bar</class> </alternatives> </beans> */ @ApplicationScoped public class Foo { public static void main(String[] args) { WeldContainer weld = new Weld().initialize(); weld.event().select(MyEvent.class).fire(new MyEvent()); } static class MyEvent { } @Qualifier @Target({FIELD, PARAMETER}) @Retention(RUNTIME) public @interface SomeQualifier { } @PostConstruct void init() { System.out.println("INIT FOO"); } void onEvent(@Observes MyEvent e) { System.out.println("EVENT FOO"); } @Alternative @Specializes static public class Bar extends Foo { @Override void init() { System.out.println("INIT BAR"); } @Override void onEvent(@Observes @SomeQualifier MyEvent e) { System.out.println("EVENT BAR"); } } } The expected output is: INIT BAR The actual output is: INIT BAR EVENT BAR Removing the @SomeQualifier annotation on the Bar#onEvent() method results in: INIT BAR EVENT BAR EVENT BAR Removing also the @Observes annotation on the Bar#onEvent() method results in: -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

6
9
0 / 0

[JBoss JIRA] (WELD-1013) Disposer method parameters not validated

by Jozef Hartinger (Created) (JIRA)

Disposer method parameters not validated ---------------------------------------- Key: WELD-1013 URL: https://issues.jboss.org/browse/WELD-1013 Project: Weld Issue Type: Bug Components: Producers (Methods, Fields and Disposers) Affects Versions: 1.1.3.SP1 Reporter: Jozef Hartinger Assignee: Jozef Hartinger Fix For: 1.1.4.Final, 2.0.0.Alpha1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (WELD-885) NPE in org.jboss.weld.wicket.util.NonContextual.<init>

by Ondrej Zizka (JIRA)

NPE in org.jboss.weld.wicket.util.NonContextual.<init> ------------------------------------------------------ Key: WELD-885 URL: https://issues.jboss.org/browse/WELD-885 Project: Weld Issue Type: Bug Components: Servlet Container Support Affects Versions: 1.0.1.Final Environment: Jetty 6.1.26 Wicket 1.4.16 Reporter: Ondrej Zizka I have a standalone app with embedded Jetty running a Wicket app. I added weld-wicket as dependency, and after I changed parent class of my WicketApplication to WeldApplication and tried to run, the NPE occured. Whole project can be seen at http://ondrazizka.googlecode.com/svn/trunk/bots/JawaBot/branches/2.0 20:56:17.343 ERROR [main] / unavailable java.lang.NullPointerException at org.jboss.weld.wicket.util.NonContextual.<init>(NonContextual.java:33) at org.jboss.weld.wicket.WeldApplication.internalInit(WeldApplication.java:50) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:723) at org.apache.wicket.protocol.http.ReloadingWicketFilter.init(ReloadingWicketFilter.java:175) at org.apache.wicket.protocol.http.WicketServlet.init(WicketServlet.java:219) at javax.servlet.GenericServlet.init(GenericServlet.java:241) at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440) at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:736) at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.jboss.jawabot.web.RunInJetty.run(RunInJetty.java:145) at org.jboss.jawabot.mod.web.WebModuleHook.initModule(WebModuleHook.java:18) at org.jboss.jawabot.JawaBotApp.initAndStartModules(JawaBotApp.java:106) at org.jboss.jawabot.JawaBotApp.main(JawaBotApp.java:53) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

4
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues November 2011