[webbeans-dev] Direction of WebBeans SE

[Pete Muir]

Hi Pete,

Yup, I see why this is happening - sorry, my bad. We can fix in the  
longer term - file an issue in JIRA.

I think you are going down the right course - in the future I want to  
switch it so that you don't have to supply these EE mocks, and Web  
Beans just disables that functionality in that environment. At that  
point we would also have an SEBootstrap and an EEBootstrap - the SE  
bootstrap would just have the class discovery stuff and resource  
loading stuff. If you want to work on that, feel free, but it's a  
little way down my priority list - below building an impl of the spec  
for EE.

I don't think your proposal around SE working through a mocked EE env  
is right - for a start, you would still need to boot the JCDI impl  
(which isn't specified), and I have a feeling it would be more  
brittle...

On 10 Mar 2009, at 00:17, Howard Moon wrote:

> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev

--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete