headers
Jozef Hartinger (JIRA | 21 May 09:45

[JBoss JIRA] (CDITCK-275) Extend test coverage for a type validation of a resource declaration (3.6.1)

Jozef Hartinger created CDITCK-275:
--------------------------------------

             Summary: Extend test coverage for a type validation of a resource declaration (3.6.1)
                 Key: CDITCK-275
                 URL: https://issues.jboss.org/browse/CDITCK-275
             Project: CDI TCK
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Tests
    Affects Versions: 1.1.0.Alpha2
            Reporter: Jozef Hartinger
            Assignee: Martin Kouba
             Fix For: 1.1.0.Alpha3

Split assertion 3.6.1 j into multiple distinct assertions, each covering a different type of resource
(persistence context, web service reference, user-defined resource, ...).

--
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
Permalink | Reply | 3 comments |
headers
Jozef Hartinger (JIRA | 21 May 09:04

[JBoss JIRA] (CDITCK-274) CreateInjectionPointTest.testInvalidParameter() too strict

Jozef Hartinger created CDITCK-274:
--------------------------------------

             Summary: CreateInjectionPointTest.testInvalidParameter() too strict
                 Key: CDITCK-274
                 URL: https://issues.jboss.org/browse/CDITCK-274
             Project: CDI TCK
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Tests
    Affects Versions: 1.1.0.Alpha2
            Reporter: Jozef Hartinger
            Assignee: Martin Kouba
             Fix For: 1.1.0.Alpha3

{quote}
The method BeanManager.createInjectionPoint() returns a container provided implementation of
InjectionPoint for
a given AnnotatedField or AnnotatedParameter or throws an IllegalArgumentException if there is a
definition error
associated with the injection point.
{quote}

However, the definition error in the NotABean class is not associated with the injection point but with an
initializer method that defines the injection point.

{code:JAVA}
public class NotABean {

    public NotABean(String name) {
(Continue reading)

Permalink | Reply | 1 comment |
headers
Adam Michalik (JIRA | 17 May 17:31

[JBoss JIRA] (WELD-1141) Bean proxy class has non-varargs method for original varargs method

Adam Michalik created WELD-1141:
-----------------------------------

             Summary: Bean proxy class has non-varargs method for original varargs method
                 Key: WELD-1141
                 URL: https://issues.jboss.org/browse/WELD-1141
             Project: Weld
          Issue Type: Bug
    Affects Versions: 1.1.8.Final
            Reporter: Adam Michalik

Test case:

@RequestScoped
public class TestVarargs {
    public void varargsMethod(String... strings) {}
}

public class TestClass {
    @Inject
    TestVarargs testVarargs;

    public void runTest() {
        testClass(testVarargs.getClass());
        testClass(TestVarargs.class);
    }

    private void testClass(Class<?> clazz) {
        for (Method m : clazz.getMethods()) {
            if (m.getName().equals("varargsMethod")) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Kouba (JIRA | 17 May 16:52

[JBoss JIRA] (WELD-1140) Dependent scoped instances injected into observer method parameters are not destroyed for non-dependent reciever

Martin Kouba created WELD-1140:
----------------------------------

             Summary: Dependent scoped instances injected into observer method parameters are not destroyed for
non-dependent reciever
                 Key: WELD-1140
                 URL: https://issues.jboss.org/browse/WELD-1140
             Project: Weld
          Issue Type: Bug
    Affects Versions: 2.0.0.Alpha2, 1.1.5.Final
            Reporter: Martin Kouba

Dependent scoped contextual instances injected into method parameters of an observer method are not
destroyed when the invocation completes in case of reciever itself is not dependent scoped.

Problematic code: {{org.jboss.weld.event.ObserverMethodImpl.sendEvent(T, Object, CreationalContext<?>)}}.

See also CDI TCK 1.1 test:
https://github.com/jboss/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/context/dependent/instance/BuiltinInstanceDependentObjectTest.java

--
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
Permalink | Reply | 3 comments |
headers
Martin Kouba (JIRA | 17 May 13:45

[JBoss JIRA] (WELD-1139) Business method interceptor bindings do not include bindings declared as meta-annotations of other interceptor bindings recursively

Martin Kouba created WELD-1139:
----------------------------------

             Summary: Business method interceptor bindings do not include bindings declared as meta-annotations of
other interceptor bindings recursively
                 Key: WELD-1139
                 URL: https://issues.jboss.org/browse/WELD-1139
             Project: Weld
          Issue Type: Bug
    Affects Versions: 2.0.0.Alpha2, 1.1.5.Final
            Reporter: Martin Kouba

It seems that only one level of inheritance is taken into account. The problem is likely in
{{Interceptors.flattenInterceptorBindings(BeanManagerImpl, Collection<Annotation>, boolean,
boolean)}} or {{InterceptorBindingModel}}.

{quote}
9.5. Interceptor resolution:
For a business method or EJB timeout method, the interceptor bindings include the interceptor bindings
declared or inherited by the bean at the class level, including, recursively, interceptor bindings
declared as meta-annotations of other interceptor bindings and stereotypes, together with all
interceptor bindings declared at the method level, including, recursively, interceptor bindings
declared as meta-annotations of other interceptor bindings.
{quote}

See also CDI TCK 1.1 test:
https://github.com/jboss/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/interceptors/definition/inheritance/resolution/InterceptorBindingResolutionTest.java

--
This message is automatically generated by JIRA.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Martin Kouba (JIRA | 17 May 13:18

[JBoss JIRA] (WELD-1138) Interceptor bindings defined on stereotype not working for session beans

Martin Kouba created WELD-1138:
----------------------------------

             Summary: Interceptor bindings defined on stereotype not working for session beans
                 Key: WELD-1138
                 URL: https://issues.jboss.org/browse/WELD-1138
             Project: Weld
          Issue Type: Bug
            Reporter: Martin Kouba

--
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
Permalink | Reply | 2 comments |
headers
Ron Šmeral (JIRA | 16 May 20:15

[JBoss JIRA] (WELD-1137) PermalinkTest fails due to dependence between test methods

Ron Šmeral created WELD-1137:
--------------------------------

             Summary: PermalinkTest fails due to dependence between test methods
                 Key: WELD-1137
                 URL: https://issues.jboss.org/browse/WELD-1137
             Project: Weld
          Issue Type: Bug
          Components: Examples
    Affects Versions: 1.1.8.Final
         Environment: JBoss EAP 6.0.0.ER7, Weld 1.1.8.Final, Oracle JDK 1.7.0_02, Solaris 10 x86
            Reporter: Ron Šmeral

{{PermalinkTest}} fails when executed on Solaris 10, even though it works in other environments.

{noformat}
java.lang.AssertionError: A name of comment's author expected
	at org.junit.Assert.fail(Assert.java:91)
	at org.junit.Assert.assertTrue(Assert.java:43)
	at org.jboss.weld.examples.permalink.ftest.PermalinkTest.permanentLinkTest(PermalinkTest.java:104)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        ...
{noformat}

The test class contains two tests --  {{permanentLinkTest}} and {{addCommentOnTopicTest}}.
The {{permanentLinkTest}} fails when it's executed first, because its success is contingent on content
generated by {{addCommentOnTopicTest}}.
Given that the order of test execution is arbitrary, {{permanentLinkTest}} actually gets executed first sometimes.
(Continue reading)

Permalink | Reply | 6 comments |
headers
AMIT RAJ KHURDHARA (JIRA | 16 May 15:13

[JBoss JIRA] (WELD-1136) First I want to know how can an end user can configure teh weld in app.

AMIT RAJ KHURDHARA created WELD-1136:
----------------------------------------

             Summary: First I want to know how can an end user can configure teh weld in app.
                 Key: WELD-1136
                 URL: https://issues.jboss.org/browse/WELD-1136
             Project: Weld
          Issue Type: Feature Request
            Reporter: AMIT RAJ KHURDHARA

--
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
Permalink | Reply | 1 comment |
headers
Stuart Douglas (JIRA | 14 May 08:44

[JBoss JIRA] (WELD-1135) Investigate faster ways of performing type safe resolution

Stuart Douglas created WELD-1135:
------------------------------------

             Summary: Investigate faster ways of performing type safe resolution
                 Key: WELD-1135
                 URL: https://issues.jboss.org/browse/WELD-1135
             Project: Weld
          Issue Type: Bug
            Reporter: Stuart Douglas
             Fix For: 1.2.0.CR1

At the moment quite a lot of bootstrap time is spent resolving injection points and events. By far the
majority of this time is spent resolving container events that form part of the portable extensions SPI.
As these events are parameterised types the resolution cannot be cached (as
ProcessAnnotatedType<ClassA> can resolve differently to ProcessAnnotatedType<ClassB> ). 

We should investigate if there is a faster way to do this, if not in the general case then at least for these
container events.

--
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
Permalink | Reply | 1 comment |
headers
Martin Kouba (JIRA | 11 May 15:01

[JBoss JIRA] (CDITCK-272) Revise tests for inheritance of member-level metadata for generic types

Martin Kouba created CDITCK-272:
-----------------------------------

             Summary: Revise tests for inheritance of member-level metadata for generic types
                 Key: CDITCK-272
                 URL: https://issues.jboss.org/browse/CDITCK-272
             Project: CDI TCK
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Martin Kouba
            Assignee: Martin Kouba
             Fix For: 1.1.0.Alpha3

--
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
Permalink | Reply | 3 comments |
headers
George Gastaldi (JIRA | 10 May 17:45

[JBoss JIRA] (WELD-1134) NPE on org.jboss.weld.util.reflection.HierarchyDiscovery

George Gastaldi created WELD-1134:
-------------------------------------

             Summary: NPE on org.jboss.weld.util.reflection.HierarchyDiscovery
                 Key: WELD-1134
                 URL: https://issues.jboss.org/browse/WELD-1134
             Project: Weld
          Issue Type: Bug
            Reporter: George Gastaldi

I upgraded Forge to Weld 1.1.8.Final, from 1.1.2.Final and now I am getting the following error:

{code}
com.google.common.collect.ComputationException: java.lang.NullPointerException
        at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:397)
        at org.jboss.weld.resources.SharedObjectCache.getTypeClosure(SharedObjectCache.java:82)
        at org.jboss.weld.resources.SharedObjectFacade.getTypeClosure(SharedObjectFacade.java:65)
        at org.jboss.weld.introspector.TypeClosureLazyValueHolder.computeValue(TypeClosureLazyValueHolder.java:52)
        at org.jboss.weld.introspector.TypeClosureLazyValueHolder.computeValue(TypeClosureLazyValueHolder.java:31)
        at org.jboss.weld.util.LazyValueHolder.get(LazyValueHolder.java:34)
        at org.jboss.weld.introspector.jlr.AbstractWeldAnnotated.getTypeClosure(AbstractWeldAnnotated.java:193)
        at org.jboss.weld.introspector.jlr.WeldMethodImpl.of(WeldMethodImpl.java:74)
        at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:261)
        at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:115)
        at org.jboss.weld.resources.ClassTransformer$TransformAnnotatedTypeToWeldClass.apply(ClassTransformer.java:88)
        at org.jboss.weld.resources.ClassTransformer$TransformAnnotatedTypeToWeldClass.apply(ClassTransformer.java:78)
        at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)
        at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
        at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
        at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
(Continue reading)

Permalink | Reply | 4 comments |

Gmane