On Thu, Jul 15, 2010 at 2:47 AM, David Blevins <[email protected]> wrote: > > On Jul 14, 2010, at 9:44 AM, Eric Covener wrote: > >> I'm doing some work with a non-openejb EJB container and looking at >> the base and openejb-specific logic >> >> OpenEJBBean.java: >> public List<Method> getRemoveMethods() >> { >> // Should we delegate to super and merge both? >> return findRemove(deploymentInfo.getBeanClass(), >> deploymentInfo.getBusinessLocalInterface()); >> } >> >> >> If we really only want to find @Remove methods from a specific >> interface (dblevins?), shouldn't it be the one we specified on the >> injection point? It doesn't seem that >> deploymentInfo.getBusinessLocalInterface() would know what iface we >> cared about (IOW the one we used to find the managed bean, or the one >> we used to get a reference from JNDI) > > Not all beans have remove methods and even if they're annotated, they could > have been overridden to not be remove methods anymore (or the reverse where > the remove method is only specified in the descriptor and not via > annotation). So probably what we need is a method somewhere (EjbPlugin?) > that OWB can use to hand a proxy over to the EJB container and say "remove". > Something like: > > OpenWebBeansEjbPlugin.remove(Object proxy) > > I know for us we can get all the information we need from just the proxy > alone. > > Thoughts? > > -David > >
Yes, I had that concern as well -- I don't think the spec wants us actually calling the remove method, just doiing what the container would have done when a remove method was called. -- Eric Covener [email protected]
