[webbeans-dev] Direction of WebBeans SE

[Howard Moon]

Hi,

Just wanted to check in about the direction I've set out in for  
WebBeans SE, as I'm not entirely sure I'm taking the right approach.  
My current strategy has been to take WebBeans RI and customise it,  
stripping out all of the EE references from the core. I've been doing  
this so far by customising the Bootstrap from WebBeans RI, providing  
it with Mock/Noop discovery strategies for EJBs and the like which  
return empty sets, thus removing the need for any EJB lookups. I also  
provided a custom class scanner (poached from Seam) which only  
searches for and registers simple web beans.

Recently a change was made to ManagerImpl (??) which added a method  
that injects an object from the Servlet API. This caused WebBeans SE  
to thow a ClassDefNotFound exception at runtime during the firing of  
the @InitialisedEvent. IIRC it was during the observer method  
resolution step - whilst it was reflecting over all the methods it  
had found it tried to instantiate the ServletContext class. As a  
"temporary" fix I simply added the servlet API to the project  
dependencies.

This got me thinking - maybe that's the correct approach to be  
taking. Rather than providing mock discovery strategies within the RI  
and disabling JNDI, why am I not simply providing a mock, in-memory  
implementation of JNDI and providing other mocks at the EJB/Servlet  
API level? That should be possible. And that will make it possible to  
also achieve the goal of WebBeans SE to being able to run on any  
implementation of JCDI, as it will only be talking to the interfaces,  
not directly to WebBeans RI implementation classes (which is  
necessary for customising the bootstrap is it not?). Then I could  
possibly execute the lifecycle in SE by calling the EE/Servlet  
lifecycle methods which will already be exposed in a standard way by  
all JCDI implementations.

Then WebBeans SE would boil down to a Main class which invokes the  
lifecycle, a set of mock EE/Servlet interfaces/implementations, and  
in-memory JNDI implementation and some other SE related stuff like  
the threading support and shutdown that I talked about on the forums.

Any thoughts? Should I change tack and start moving the mocking out  
to the Servlet/EE/standard API level, and remove my customisations to  
WebBeans RI classes? Or should I keep going the way I'm going, the  
aim of which was to produce a WebBeans RI spinoff with everything EE  
related stripped out entirely? Or is there a better third option  
which I haven't thought of yet?

Feedback appreciated,

Pete.