On 10 Nov 2008, at 18:15, Nicklas Karlsson wrote:
Hi,
I like the merging of the model into the bean, one less hierarchy to
keep in mind when implementing. I'm not quite sure I get the
XmlSimpleBean, though.
Looking at e.g. AbstractClassBean.initInitializerMethods(), it is
split into two parts based on the isDefinedInXml(). Couldn't the
initInitializerMethods() itself had been abstract and implemented in
different ways in the subclasses?
Yes. However, for example, XmlEnterpriseBean and XmlSimpleBean share
the same way of declaring initializers in xml. If we did the
initInitializerMethods() as a superclass override (e.g. in XmlSimpleBean
public void initInitializerMethods() {
// Do XML init
...
// Do Java init
super.initInitializerMethods();
}
then we end up repeating this logic in both XmlEnterpriseBean and
XmlSimpleBean.
Maybe the simplicity of doing it this way is outweighs the
repetition....
Another (unrelated) thing that came to mind is the implementation of
the Web Bean itself. Is it operating against the client proxy or is
the client proxy merged as an interceptor in the overall Web Bean?
The client proxy (aka ScopeAdaptor) is totally separate (currently)
from any proxy which contains the interceptors etc. It's much simpler
to keep these things separate for now, even though we end up nesting
proxies.
clientProxy
instanceProxy
instance
How
similar is the implementation going to be to the Seam
Component/interceptor stack/invocation context stuff?
Ophir?
PS. Did the spec announcement ever run on InfoQ?
---
Nik
_______________________________________________
webbeans-dev mailing list
webbeans-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev