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
> >>>>> [email protected]
> >>>>> https://lists.jboss.org/mailman/listinfo/weld-dev
> >>>> 
> >>>> 
> >>>> _______________________________________________
> >>>> weld-dev mailing list
> >>>> [email protected]
> >>>> https://lists.jboss.org/mailman/listinfo/weld-dev
> >>> 
> >>> 
> >>> _______________________________________________
> >>> weld-dev mailing list
> >>> [email protected]
> >>> https://lists.jboss.org/mailman/listinfo/weld-dev
> >> 
> > 
> > 
> 


_______________________________________________
weld-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-dev

Reply via email to