I just added Bootstrap, which exposes
public void registerBeans(Class<?>...classes);
the method will register any classes passed as enterprise or simple
web beans as needed, and also add all producer methods.
AbstractTest creates a new Bootstrap which you can use in tests.
Next up is making an implementation of the WebBeanDiscovery SPI for
would you be able to explain what is motivating the use of a
"3-layered" approach to the Bean implementations?
I'm finding the resulting parallel class hierarchies really difficult
to work with. In particular, I got totally stuck on the implementation
of MethodConstructor.invoke() for producer methods.
I really think the code would end up a lot more elegant if we
flattened stuff out into the Bean subclasses...
T E S T S
log4j:WARN No appenders could be found for logger
log4j:WARN Please initialize the log4j system properly.
Tests run: 200, Failures: 5, Errors: 0, Skipped: 0, Time elapsed:
1.825 sec <<< FAILURE!
Tests run: 200, Failures: 5, Errors: 0, Skipped: 0
Folks, this <exclude> stuff in test-ng.xml is a problem.
Right now we are down to less than 180 tests from almost 220. and my
guess is this is because a bunch of tests that are actually passing
have been accidentally excluded.
Nick, I think some of your tests fall into this category. Am I right?
The real danger is that there are failing tests, that *should* pass,
which have been excluded.
I like the merging of the model into the bean, one less hierarchy to
keep in mind when implementing. I'm not quite sure I get the
Looking at e.g. AbstractClassBean.initInitializerMethods(), it is
split into two parts based on the isDefinedInXml(). Couldn't the
initInitializerMethods() itself had been abstract and implemented in
different ways in the subclasses?
Another (unrelated) thing that came to mind is the implementation of
the Web Bean itself. Is it operating against the client proxy or is
the client proxy merged as an interceptor in the overall Web Bean? How
similar is the implementation going to be to the Seam
Component/interceptor stack/invocation context stuff?
PS. Did the spec announcement ever run on InfoQ?
Eeek, that's a bug in the spec. Thanks!
It should read:
"If an enterprise Web Bean defined using annotations does not
explicitly declare a Web Bean remove method using @Destructor, and
exactly one remove method that accepts no parameters exists, then that remove
method is the Web Bean remove method. Otherwise, if no remove method
that accepts no parameters exists, or more than one remove method
that accepts no parameters exists, the enterprise Web Bean has no Web
Bean remove method."
On Wed, Nov 12, 2008 at 1:56 AM, Nicklas Karlsson <nickarls(a)gmail.com> wrote:
> Section "126.96.36.199. Declaring a Web Bean remove method using annotations." says
> "If an enterprise Web Bean defined using annotations does not
> explicitly declare a Web Bean remove method using @Destructor, and a
> remove method that accepts no parameters exists, then that remove
> method is the Web Bean remove method. Otherwise, if no remove method
> that accepts no parameters exists, the enterprise Web Bean has no Web
> Bean remove method."
> What should be done if there are multiple remove methods that accept
> no parameters? Throw a DefinitionException?
So I've been trying to figure out what's the best way to get people
interested in learning more about Web Beans, and I'm thinking we
should aim to get a decent example application up and running for the
alpha release. In fact, I'm inclined to think that should be the new
definition of the alpha release: enough functionality to run a decent
web app. Which I guess probably means shuffling some stuff in the
So the new critical path to the alpha is:
* Web Bean discovery & initialization event
* Java EE integration
* session context
* JSF integration (or should it be a Wicket demo instead?)
* basic support for enterprise Web Beans
* Web Bean remove methods
Anything else which isn't done by the time we release the alpha can
wait til the next release (alpha2?).
Pete, WDYT? And how long do you think it takes to get that list of stuff done?
Of course, the app would be much cooler if it had events in it. David,
what is the true current status of work on the event bus?
Yeah, I hate it, but it probably does make sense.
Send the proposal to the web beans group, I suppose.
On Fri, Nov 7, 2008 at 12:05 AM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
> I have a suggestion for Web Beans regarding the convention used by the
> @Named annotation. The nice part about this annotation is that it
> doesn't require the use of a string value to create a name that maps
> to the class name. In ~80% of cases, that is what people would do
> anyway. However, for framework builders, I can see them wanting to
> create fully-qualified names like in Seam to avoid naming conflicts.
> Would it be reasonable to propose adding an attribute to the @Named
> annotation that indicates the Java package should be prepended to the
> calculated name?
> @Named(qualified = true)
> That would avoid people slipping into the non-type safe pattern of:
> Dan Allen
> Software consultant | Author of Seam in Action
> 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.
On Fri, Nov 7, 2008 at 1:23 AM, Nicklas Karlsson <nickarls(a)gmail.com> wrote:
> Currently it appears to be possible to get a reference to a context
> from manager and call get with a bean of any scopetype and create=true
> and end up with the instance in that scope. Is this the desired behaviour?
Hmmm. Interesting point. I suppose we should add to the spec that Context
should throw an exception if the scope of the given bean does not match.
> Bean instances created manually from Context.get also has no client
> proxy since it is applied at manager level but I understood from Pete
> that this should be the case(?)
Yes, that's correct. Context is not supposed to be called directly by the
In case you have a minute or five, it would be good to start hearing what
kind of tooling we should consider adding for webbeans in the next rev of
Pete and I already did a few suggestions while we were in Copenhagen you
can see here:
If you got some concrete ones add them to jira directly or put the
suggestions on this list for dicsussion.