[weld-dev] Tests failures

Pete Muir pmuir at redhat.com
Tue May 25 11:49:56 EDT 2010


On 25 May 2010, at 16:44, David Allen wrote:

> Yes, I already found that out regarding that test and already made the
> changes necessary for the EJB proxy.  Now it is also needed for the
> client proxy.

Exactly, the change I did to the EnterpriseProxyFactory to add all types which are interfaces (which is what fixed the EJB proxy) is really a hack, I think we have to redesign proxies to not be so superclass orientated. We should only add the bean types to the proxy for any proxy. At the moment we take the instance type, and work out what it's types are - IMO this is wrong, we know exactly what types the bean has (bean.getTypes()) and so we should use that. There is some trickery (but also existing code in TypeInfo) to establish from that set what the superclass is, if there is one. If there isn't, Object.class should be the superclass.

Agreed?

> The testSerializeSFSB test is broken due to perhaps changes in the
> design of JBoss EJB.  It is now trying to serialize MC classes which
> then cannot be deserialized because they are not available through the
> classloader used by the app.  This still requires some investigation to
> see if some part of the handler should actually not be serialized, or if
> so, how the correct CL is going to be obtained for MC beans.
> 
> - David
> 
> Am Dienstag, den 25.05.2010, 15:47 +0100 schrieb Pete Muir:
>> On 25 May 2010, at 15:25, Pete Muir wrote:
>> 
>>> David, can you concentrate on the testSerializeSFSB.
>>> 
>>> I am getting to testRemoveEjbIgnored right now.
>> 
>> Ok, I found that the problem is the same as we discussed before - that the current proxying is too super-class centric. Because non no-interface-view ejbs don't really have a super class, the ContextBeanInstance is picking one of the two business interfaces (essentially at random hence why the test sometimes works) as the super class, not considering both.
>> 
>> I could hack this so that we make sure all interfaces are added, but I think it is better to redo the proxies to support using multiple interfaces with Object.class as the superclass. David, WDYT?
>> 
>>> 
>>> On 24 May 2010, at 19:38, David Allen wrote:
>>> 
>>>> The last two tests now pass.  The first one still fails and will need
>>>> further investigation.  There also appears to be yet another failure
>>>> regarding the remove method test for EJBs.  I'll take a look at that one
>>>> too.
>>>> 
>>>> Am Freitag, den 21.05.2010, 22:57 +0100 schrieb Pete Muir:
>>>>> All
>>>>> 
>>>>> I've worked through the incontainer test failures we were seeing with Weld, and I am now down to these locally:
>>>>> 
>>>>> testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest)
>>>>> testPassivationOfPersistenceContext(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
>>>>> testPassivationOfPersistenceUnit(org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest)
>>>>> 
>>>>> All of which are related to serialization of proxies. David is going to take a look on Sunday at these.
>>>>> 
>>>>> If you see other failures locally, please investigate or discuss :-)
>>>>> 
>>>>> Pete
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> weld-dev mailing list
>>>>> weld-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> weld-dev mailing list
>>>> weld-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>> 
>>> 
>>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>> 
> 
> 




More information about the weld-dev mailing list