Re: [webbeans-dev] Direction of WebBeans SE

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. _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev