[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, 3 months
[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, 3 months
[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, 3 months
[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, 3 months
[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, 3 months
[JBoss JIRA] Created: (CDITCK-213) Interceptor classes in TCK do not follow the Interceptor spec
by Bob Nettleton (JIRA)
Interceptor classes in TCK do not follow the Interceptor spec
-------------------------------------------------------------
Key: CDITCK-213
URL: https://issues.jboss.org/browse/CDITCK-213
Project: CDI TCK
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Tests
Affects Versions: 1.0.4.Final
Reporter: Bob Nettleton
There are some interceptor-related suites in the CDI TCK that are not portable in some situations. The interceptor classes listed here:
org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.interceptorOrder.MissileInterceptor
org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.MissileInterceptor
org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.simpleInterception.MissileInterceptor
These interceptor classes do not have a public, no-args constructor, which is required by the Interceptor 1.1 specification. This means that the tests may not be portable to all environments, since application servers may choose to treat this as an error condition.
The following tests are affected by this issue:
org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.interceptorOrder.SessionBeanInterceptorOrderTest.testInterceptorsDeclaredUsingInterceptorsCalledBeforeInterceptorBinding
org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.SessionBeanInterceptorOnNonContextualEjbReferenceTest.testNonContextualSessionBeanReferenceIsIntercepted
org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.simpleInterception.SessionBeanInterceptorDefinitionTest.testSessionBeanIsIntercepted
I request that these tests be excluded from the 1.0.4 suite, and that the interceptors be fixed for subsequent versions of the test suite.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] Created: (CDITCK-219) SessionContextTest.testSessionContextDestroyedWhenHttpSessionTimesOut uses too short of a sleep delay time
by Bob Nettleton (JIRA)
SessionContextTest.testSessionContextDestroyedWhenHttpSessionTimesOut uses too short of a sleep delay time
----------------------------------------------------------------------------------------------------------
Key: CDITCK-219
URL: https://issues.jboss.org/browse/CDITCK-219
Project: CDI TCK
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Tests
Affects Versions: 1.0.4.Final
Reporter: Bob Nettleton
The following test case:
org.jboss.jsr299.tck.tests.context.session.SessionContextTest.testSessionContextDestroyedWhenHttpSessionTimesOut
uses the following line to sleep after asking the application server to invalidate the session:
" Thread.sleep(1500);"
The test attempts to verify that the session context is destroyed properly after the timeout.
The problem with this test is that it appears as if it could potentially introduce a timing problem. Since Thread.sleep() behaves slightly differently for each platform, and as far as I can tell is not even guaranteed to sleep as long as requested in some situations, there is a chance that the client may make the second request before 1.5 seconds has expired. Since the behavior of System.getTimeMillis() is also system-dependent, I'd be inclined to think that 1.5 seconds is probably not a long enough timeout in order to keep this test from having intermittent failures.
I request that this test case be excluded, and that this test be modified in a later version of the TCK to use a larger sleep value.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months