[webbeans-dev] web-beans.xml in reference guide
by Dan Allen
In the Web Beans reference guide, there are still references to
web-beans.xml. I believe the name of this file was changed to beans.xml.
Should I update the reference guide when I see inconsistencies like this, or
is there a global effort still outstanding?
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
17 years
[webbeans-dev] Direction of WebBeans SE
by 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.
17 years
[webbeans-dev] package of @Model
by Mark Struberg
Hi!
The spec does not cover in which package the @Model should go.
The ri has it in the 'old' javax.webbeans package which has been killed a while ago.
The package section of the Spec doesn't cover it at all.
So in which package should @Model finally end?
txs and LieGrue,
strub
17 years
[webbeans-dev] TCK Question
by Gurkan Erdogdu
Hi guys,
While executing the standalone TCK tests related with "Event and Observers", I tackled the one point.
Specification says that whenever the bean uses the @Fires annotation on its class field, like @Fires Event<T>, container provides the implicit bean component. But it does/may not say that you have to add this implicit bean component to the "Manager"'s beans bag. So when resolving the implicit event object with Manager#resolveByType method, our implementation returns no bean.
What we do is that whenever the field injection is annotated with @Fires, we create a new implicit bean object and add it into the bean Dependent context, but not add this implicit bean into the Manager's bag.
But in the TCK, it requires that Manager adds this implicit bean into its bag.
Actually, these are also applied for all implicit beans except the Manager and Conversation beans.
WDYT?
/Gurkan
17 years
[webbeans-dev] TCK Tests - Dependent Context Activation
by Gurkan Erdogdu
Hi;
Specification states that depending context is active --> "while an observer method is invoked", but it does not state that where is the starting point for the activation. In the TCK tests, it is activated on the Manager#fireEvent.
But currently in the OpenWebBeans project, we activate the Dependent Context at the start of the Observer#notify method.
Which one is correct?
Thanks;
/Gurkan
17 years
