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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete