July 2011 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-908) Random NPE while serializing bean sent

by Yannick Menager (JIRA)

Random NPE while serializing bean sent --------------------------------------- Key: WELD-908 URL: https://issues.jboss.org/browse/WELD-908 Project: Weld Issue Type: Bug Affects Versions: 1.1.0.Final Environment: Glassfish 3.1 Reporter: Yannick Menager The problem happens randomly (like 50% of the time), when calling an EJB through it's remote interface, and passing a Session scoped object as an argument, resulting in an NPE: java.lang.NullPointerException at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1088) at java.io.ObjectOutputStream.writeUnshared(ObjectOutputStream.java:397) at org.jboss.weld.bean.proxy.util.SerializableProxy.writeObject(SerializableProxy.java:92) at sun.reflect.GeneratedMethodAccessor125.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.corba.ee.impl.io.IIOPOutputStream.invokeObjectWriter(IIOPOutputStream.java:646) at com.sun.corba.ee.impl.io.IIOPOutputStream.outputObject(IIOPOutputStream.java:612) at com.sun.corba.ee.impl.io.IIOPOutputStream.simpleWriteObject(IIOPOutputStream.java:196) at com.sun.corba.ee.impl.io.ValueHandlerImpl.writeValueInternal(ValueHandlerImpl.java:235) at com.sun.corba.ee.impl.io.ValueHandlerImpl.writeValueWithVersion(ValueHandlerImpl.java:216) at com.sun.corba.ee.impl.io.ValueHandlerImpl.writeValue(ValueHandlerImpl.java:180) at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.callWriteValue(CDROutputStream_1_0.java:852) at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.writeRMIIIOPValueType(CDROutputStream_1_0.java:837) at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:962) at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:976) at com.sun.corba.ee.impl.encoding.CDROutputObject.write_value(CDROutputObject.java:521) at com.sun.corba.ee.impl.corba.TCUtility.marshalIn(TCUtility.java:157) at com.sun.corba.ee.impl.corba.AnyImpl.write_value(AnyImpl.java:627) at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_any(CDROutputStream_1_0.java:627) at com.sun.corba.ee.impl.encoding.CDROutputObject.write_any(CDROutputObject.java:489) at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.writeAny(Util.java:366) at com.sun.corba.ee.impl.io.ValueHandlerImpl.write_Array(ValueHandlerImpl.java:499) at com.sun.corba.ee.impl.io.ValueHandlerImpl.writeValueInternal(ValueHandlerImpl.java:233) at com.sun.corba.ee.impl.io.ValueHandlerImpl.writeValueWithVersion(ValueHandlerImpl.java:216) at com.sun.corba.ee.impl.io.ValueHandlerImpl.writeValue(ValueHandlerImpl.java:180) at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.callWriteValue(CDROutputStream_1_0.java:852) at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.writeArray(CDROutputStream_1_0.java:768) at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:949) at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:976) at com.sun.corba.ee.impl.encoding.CDROutputObject.write_value(CDROutputObject.java:521) at com.sun.corba.ee.impl.copyobject.ORBStreamObjectCopierImpl.copy(ORBStreamObjectCopierImpl.java:76) at com.sun.corba.ee.impl.copyobject.ORBStreamObjectCopierImpl.copy(ORBStreamObjectCopierImpl.java:65) at com.sun.corba.ee.impl.orbutil.copyobject.FallbackObjectCopierImpl.copy(FallbackObjectCopierImpl.java:69) at com.sun.corba.ee.impl.orbutil.copyobject.FallbackObjectCopierImpl.copy(FallbackObjectCopierImpl.java:59) at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.copyObject(Util.java:771) at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.copyObjects(Util.java:742) at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.copyArguments(DynamicMethodMarshallerImpl.java:439) at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:227) at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152) ------------------------------------------ import java.io.Serializable; public class TestObj implements Serializable{ private String val; public TestObj() { } public TestObj(String val) { this.val = val; } public String getVal() { return val; } public void setVal(String val) { this.val = val; } } ------------------------------------------ @RequestScoped @Named("test") public class TestWeb { @EJB private RemoteService remoteService; @Inject private TestObj testObj; @Produces @SessionScoped public TestObj create() { return new TestObj("ads"); } public String getVal() { return remoteService.test(testObj); } } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
2
0 / 0

[JBoss JIRA] Created: (WELD-939) javax.inject-1's @Named does not have @Target

by Ondrej Zizka (JIRA)

javax.inject-1's @Named does not have @Target --------------------------------------------- Key: WELD-939 URL: https://issues.jboss.org/browse/WELD-939 Project: Weld Issue Type: Bug Reporter: Ondrej Zizka Priority: Minor @Named in javax.inject-1 artifact taken from jboss.org repo does not have @Target. Weld reports it: 18:49:15.594 DEBUG [main] org.jboss.weld.Reflection WELD-000601 interface javax.inject.Named is missing @Target. Weld will use this annotation, however this may make the application unportable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
2
0 / 0

[JBoss JIRA] Created: (WELD-944) Improve error message for missing interceptor's class.

by Ondrej Zizka (JIRA)

Improve error message for missing interceptor's class. ------------------------------------------------------ Key: WELD-944 URL: https://issues.jboss.org/browse/WELD-944 Project: Weld Issue Type: Enhancement Reporter: Ondrej Zizka Based on WELD-940: When an interceptor or decorator is defined in beans.xml, but the class is missing, current error message is a bit misleading: {quote} WELD-001417 Enabled interceptor class <class>org.jboss.weld.environment.se.jpa.JpaTransactionInterceptor</class> in jar:file:/mnt/ssd1/data/.m2/repository/org/jboss/jawabot/JawaBot-core/2.0.0-SNAPSHOT/JawaBot-core-2.0.0-SNAPSHOT.jar!/META-INF/beans.xml@11 is neither annotated @Interceptor nor registered through a portable extension at org.jboss.weld.bootstrap.Validator.validateEnabledInterceptorClasses(Validator.java:466) {quote} Maybe we should check whether the class is loaded, and if not, log WARN or ERROR about it. -- 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-933) Validator.validateBean doesn't handle @Typed properly

by Mike Mosiewicz (JIRA)

Validator.validateBean doesn't handle @Typed properly ----------------------------------------------------- Key: WELD-933 URL: https://issues.jboss.org/browse/WELD-933 Project: Weld Issue Type: Bug Components: Bootstrap and Metamodel API, Proxies Affects Versions: 1.1.0.CR3 Environment: JBoss 6.0.0.Final Reporter: Mike Mosiewicz Here is the problem. I've got @Typed class becouse I wanted to limit the set of proxies generated by weld becouse it's ancestors would not be proxyable. That's why I tried @Typed. And halfway it works. But just halfway. The problem I notice is here in Validator (lines 142-145) if (normalScoped && !Beans.isBeanProxyable(bean)) { throw Proxies.getUnproxyableTypesException(bean.getTypes()); } My @Typed class which is annotated like this: @Named("catalogEntityHome") @ConversationScoped @Typed(CatalogEntityHome.class) public class CatalogEntityHome extends BasicDAO<CatalogEntity, ObjectId> implements Serializable { .. The problem I observe is that Beans.isBeanProxyable checks Proxies.getUnproxyableTypesException(bean) which somehow produces non-null result. However a moment later it checks Proxies.getUnprox....(bean.getTypes()), which turns to be null. And that's what it tries to throw, like here: 09:32:58,035 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: name=vfs:///C:/servers/jboss-6.0.0.Final/server/default/deploy/test.war_WeldBootstrapBean state=Create: java.lang.NullPointerException at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:144) [:6.0.0.Final] at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:162) [:6.0.0.Final] at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:377) [:6.0.0.Final] at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:363) [:6.0.0.Final] at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:388) [:6.0.0.Final] at org.jboss.weld.integration.deployer.env.helpers.BootstrapBean.boot(BootstrapBean.java:92) [:6.0.0.Final] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
2
0 / 0

[JBoss JIRA] Created: (WELD-817) Wrap Contexutal impls passed to Contexts in a serializable wrapper if the context is passivation capable

by Pete Muir (JIRA)

Wrap Contexutal impls passed to Contexts in a serializable wrapper if the context is passivation capable -------------------------------------------------------------------------------------------------------- Key: WELD-817 URL: https://issues.jboss.org/browse/WELD-817 Project: Weld Issue Type: Feature Request Reporter: Pete Muir Fix For: 1.2.0.Beta1 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
4
0 / 0

[JBoss JIRA] Created: (WELD-765) Simplify access to a deployment's BeanManager, when its id (or the BDA id) is known

by Marius Bogoevici (JIRA)

Simplify access to a deployment's BeanManager, when its id (or the BDA id) is known ----------------------------------------------------------------------------------- Key: WELD-765 URL: https://jira.jboss.org/browse/WELD-765 Project: Weld Issue Type: Feature Request Components: Weld SPI Affects Versions: 1.1.0.Beta2 Reporter: Marius Bogoevici Fix For: 1.1.0.Beta3 Currently, the BM id and BDA ID are practically equivalent. Retrieving the BeanManager if said ID is known requires iterating Deployment.getBeanDeploymentArchives() until the BDA is found and then retrieving the BeanManager from the deployment by using Bootstrap.getManager(BeanDeploymentArchive beanDeploymentArchive). This can be simplified by introducing Deployment.getBeanDeploymentArchive(String BDAid). Another possibility is to provide Bootstrap.getManager(String bdaID). Both variants would simplify the access code and make it work faster. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

5
5
0 / 0

[JBoss JIRA] Created: (WELD-627) Clarify the implementation and usage of WeldClass.getWeldMethods, WelldClass.getDeclaredWeldMethods

by Marius Bogoevici (JIRA)

Clarify the implementation and usage of WeldClass.getWeldMethods, WelldClass.getDeclaredWeldMethods --------------------------------------------------------------------------------------------------- Key: WELD-627 URL: https://jira.jboss.org/browse/WELD-627 Project: Weld Issue Type: Bug Components: Bootstrap and Metamodel API Affects Versions: 1.0.1.Final Reporter: Marius Bogoevici Fix For: 1.1.0.BETA2 The goal for getWeldMethods and getDeclaredWeldMethods is to mimic the behavior of getMethods and getDeclaredMethods as they are defined on java.lang.Class. Introduce a new method - called e.g. getWeldBusinessMethods that returns the methods of the class that can be used for business methods invocations on a particular bean. -- 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

12 years, 10 months

5
8
0 / 0

[JBoss JIRA] Created: (WELD-516) RunnableDecorator incorrectly assumes >0 Runnable beans

by Morten Christensen (JIRA)

RunnableDecorator incorrectly assumes >0 Runnable beans ------------------------------------------------------- Key: WELD-516 URL: https://jira.jboss.org/jira/browse/WELD-516 Project: Weld Issue Type: Bug Affects Versions: 1.0.1.Final Environment: Java 6 + WeldSE Reporter: Morten Christensen The class org.jboss.weld.environment.se.threading.RunnableDecorator incorrectly assumes that there will be at least one bean that implements Runnable. If there are no beans that implements Runnable then an error like this will happen: org.jboss.weld.DeploymentException: Injection point has unstatisfied dependencies. Injection point: field org.jboss.weld.environment.se.threading.RunnableDecorator.runnable; Qualifiers: [@javax.enterprise.inject.Default()] at org.jboss.weld.Validator.validateInjectionPoint(Validator.java:232) at org.jboss.weld.Validator.validateBean(Validator.java:80) at org.jboss.weld.Validator.validateRIBean(Validator.java:100) at org.jboss.weld.Validator.validateBeans(Validator.java:282) at org.jboss.weld.Validator.validateDeployment(Validator.java:267) at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:389) at org.jboss.weld.environment.se.Weld.initialize(Weld.java:81) at org.jboss.weld.environment.se.StartMain.go(StartMain.java:45) at org.jboss.weld.environment.se.StartMain.main(StartMain.java:57) I guess the field "runnable" inside this class should be changed to use Instance<Runnable> instead. -- 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

6
12
0 / 0

[JBoss JIRA] Created: (CDI-34) Make special note in the spec about @Named beans (via a stereotype) cannot be selected with Instance.select()

by Shane Bryzak (JIRA)

Make special note in the spec about @Named beans (via a stereotype) cannot be selected with Instance.select() ------------------------------------------------------------------------------------------------------------- Key: CDI-34 URL: https://issues.jboss.org/browse/CDI-34 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Shane Bryzak Priority: Minor For example, say we have the following bean: public @Model class Foo implements IFoo { } And we have the following injection point within another bean: @Inject Instance<Foo> fooInstance; It is not possible to select Foo via name using the Instance: // This results in an UnsatisfiedDependencyException Foo foo = fooInstance.select(new NamedLiteral("foo")).get(); Instead, Foo must be annotated directly with the @Named annotation itself: /* * This Foo can be selected by name */ public @Named @RequestScoped Foo implements IFoo { } This special case might be worthwhile mentioning in the next revision of the spec. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
7
0 / 0

[JBoss JIRA] Created: (CDITCK-212) DestroyedInstanceReturnedByGetTest assumes that the application scope can be destroyed and then re-created

by Stuart Douglas (JIRA)

DestroyedInstanceReturnedByGetTest assumes that the application scope can be destroyed and then re-created ---------------------------------------------------------------------------------------------------------- Key: CDITCK-212 URL: https://issues.jboss.org/browse/CDITCK-212 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Stuart Douglas Context applicationContext = getCurrentManager().getContext(ApplicationScoped.class); destroyContext(applicationContext); setContextActive(applicationContext); myApplicationBeanInstance = applicationContext.get(myApplicationBean); The spec does not require that the application scope can be destroyed and re-created, if fact it could be argued that this behaviour violates the spec, as the application context is supposed to last for the lifetime of the application. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues July 2011