[weld-issues] [JBoss JIRA] (CDITCK-220) BuiltInBeansTest.testUserTransactionBean()
[
https://issues.jboss.org/browse/CDITCK-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666757#comment-12666757
]
Martin Kouba commented on CDITCK-220:
-
Fixed in 1.1 branch.
BuiltInBeansTest.testUserTransactionBean()
--
Key: CDITCK-220
URL: https://issues.jboss.org/browse/CDITCK-220
Project: CDI TCK
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Tests
Affects Versions: 1.0.4.Final
Reporter: David Blevins
Fix For: 1.0.5.CR1
We're passing this test, but wanted to drop a note that it should be updated.
We just need to update this bean like so:
{code}
@Stateful
@TransactionManagement(BEAN)
public class UserTransactionInjectedBean implements
UserTransactionInjectedBeanLocal
{
@Inject transient UserTransaction userTransaction;
public UserTransaction getUserTransaction()
{
return userTransaction;
}
}
{code}
Only @Stateful session bean explicitly marked as @TransactionManagement(BEAN)
are allowed to get UserTransaction via lookup or injection, the EJB TCK tests
cover this pretty well. In OpenEJB we have deploy-time checks for this if
@Resource is used to get a UserTransaction and we'd like to expand that
checking to properly cover @Inject injection as well. Even though we are
currently injecting that object and passing the test, it's a false pass and
at runtime that UserTransaction object is hardwired to throw exceptions if
used by a non-CMT bean.
--
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
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-220) BuiltInBeansTest.testUserTransactionBean()
[
https://issues.jboss.org/browse/CDITCK-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Kouba reassigned CDITCK-220:
---
Assignee: Martin Kouba
BuiltInBeansTest.testUserTransactionBean()
--
Key: CDITCK-220
URL: https://issues.jboss.org/browse/CDITCK-220
Project: CDI TCK
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Tests
Affects Versions: 1.0.4.Final
Reporter: David Blevins
Assignee: Martin Kouba
Fix For: 1.0.5.CR1, 1.1.0.Alpha2
We're passing this test, but wanted to drop a note that it should be updated.
We just need to update this bean like so:
{code}
@Stateful
@TransactionManagement(BEAN)
public class UserTransactionInjectedBean implements
UserTransactionInjectedBeanLocal
{
@Inject transient UserTransaction userTransaction;
public UserTransaction getUserTransaction()
{
return userTransaction;
}
}
{code}
Only @Stateful session bean explicitly marked as @TransactionManagement(BEAN)
are allowed to get UserTransaction via lookup or injection, the EJB TCK tests
cover this pretty well. In OpenEJB we have deploy-time checks for this if
@Resource is used to get a UserTransaction and we'd like to expand that
checking to properly cover @Inject injection as well. Even though we are
currently injecting that object and passing the test, it's a false pass and
at runtime that UserTransaction object is hardwired to throw exceptions if
used by a non-CMT bean.
--
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
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-220) BuiltInBeansTest.testUserTransactionBean()
[
https://issues.jboss.org/browse/CDITCK-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Kouba updated CDITCK-220:
Fix Version/s: 1.1.0.Alpha2
BuiltInBeansTest.testUserTransactionBean()
--
Key: CDITCK-220
URL: https://issues.jboss.org/browse/CDITCK-220
Project: CDI TCK
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Tests
Affects Versions: 1.0.4.Final
Reporter: David Blevins
Fix For: 1.0.5.CR1, 1.1.0.Alpha2
We're passing this test, but wanted to drop a note that it should be updated.
We just need to update this bean like so:
{code}
@Stateful
@TransactionManagement(BEAN)
public class UserTransactionInjectedBean implements
UserTransactionInjectedBeanLocal
{
@Inject transient UserTransaction userTransaction;
public UserTransaction getUserTransaction()
{
return userTransaction;
}
}
{code}
Only @Stateful session bean explicitly marked as @TransactionManagement(BEAN)
are allowed to get UserTransaction via lookup or injection, the EJB TCK tests
cover this pretty well. In OpenEJB we have deploy-time checks for this if
@Resource is used to get a UserTransaction and we'd like to expand that
checking to properly cover @Inject injection as well. Even though we are
currently injecting that object and passing the test, it's a false pass and
at runtime that UserTransaction object is hardwired to throw exceptions if
used by a non-CMT bean.
--
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
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-219) SessionContextTest.testSessionContextDestroyedWhenHttpSessionTimesOut uses too short of a sleep delay time
[ https://issues.jboss.org/browse/CDITCK-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba resolved CDITCK-219. - Assignee: Martin Kouba Fix Version/s: 1.1.0.Alpha2 Resolution: Done Sleep interval increased to 3000ms. 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 Assignee: Martin Kouba Fix For: 1.1.0.Alpha2 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. 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 ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-217) InjectionIntoWebServiceEndpoint test uses hard-coded HTTP port
[ https://issues.jboss.org/browse/CDITCK-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba resolved CDITCK-217. - Assignee: Martin Kouba Fix Version/s: 1.1.0.Alpha1 Resolution: Done InjectionIntoWebServiceEndpoint test uses hard-coded HTTP port -- Key: CDITCK-217 URL: https://issues.jboss.org/browse/CDITCK-217 Project: CDI TCK Issue Type: Bug Security Level: Public(Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: Bob Nettleton Assignee: Martin Kouba Fix For: 1.1.0.Alpha1 The following test in the CDI TCK: org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.ws.InjectionIntoWebServiceEndPointTest.testInjectionIntoWebServiceEndpoint appears to use a hard-coded HTTP port in the following web service client class: org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.ws.SheepWSEndPointService This test is quite different from the rest of the suite, in that the configured HTTP port is not used in this client. It appears that the test is non-portable in its current state. I request that this test be excluded. Thanks. -- 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 ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-213) Interceptor classes in TCK do not follow the Interceptor spec
[ https://issues.jboss.org/browse/CDITCK-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba resolved CDITCK-213. - Assignee: Martin Kouba Fix Version/s: 1.1.0.Alpha1 Resolution: Done 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 Assignee: Martin Kouba Fix For: 1.0.5.CR1, 1.1.0.Alpha1 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. 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 ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-212) DestroyedInstanceReturnedByGetTest assumes that the application scope can be destroyed and then re-created
[ https://issues.jboss.org/browse/CDITCK-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba resolved CDITCK-212. - Assignee: Martin Kouba Fix Version/s: 1.1.0.Alpha2 Resolution: Done Questionable code removed. 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 Assignee: Martin Kouba Fix For: 1.1.0.Alpha2 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. 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 ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-211) Test that beans which are @Named via a stereotype are selectable with Instance.select()
[
https://issues.jboss.org/browse/CDITCK-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666798#comment-12666798
]
Pete Muir commented on CDITCK-211:
--
I think you are probably right Martin.
Test that beans which are @Named via a stereotype are selectable with
Instance.select()
---
Key: CDITCK-211
URL: https://issues.jboss.org/browse/CDITCK-211
Project: CDI TCK
Issue Type: Bug
Security Level: Public(Everyone can see)
Reporter: Shane Bryzak
Assignee: Martin Kouba
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 InstanceFoo fooInstance;
Check that it is possible to select it
// This must not result in an UnsatisfiedDependencyException
Foo foo = fooInstance.select(new NamedLiteral(foo)).get();
--
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
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
