Am Dienstag, den 25.05.2010, 16:49 +0100 schrieb Pete Muir:
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?
Yup, already reached that conclusion.
> 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
>>
>
>