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(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/weld-dev
>>>
>>>
>>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/weld-dev
>