[webbeans-dev] Using Web Beans Trunk with JBoss 5.2
by Pete Muir
Hi guys,
I forgot to mention to you all, if you are running TCK tests in trunk,
you must use a JBoss AS 5.2 snapshot newer than around 15th September
(after this date, AS 5.2 included Bean Validation support).
15 years, 3 months
[webbeans-dev] PFD2 section changes
by Shane Bryzak
For reference when updating TCK tests, etc, here's a list of the section
changes between versions 1.0.20090625 and PFD2 of the spec.
PFD2 section changes
====================
Old Section New section
----------------------------------------------------------------------------------------
3.1.4 Bean constructors 3.7
3.1.4.1 Declaring a bean constructor 3.7.1
3.1.4.2 Bean constructor parameters 3.7.2
3.1.5 Specializing a managed bean 3.1.4
3.1.6 Default name for a managed bean 3.1.5
3.7 Injected fields 3.8
3.7.1 Declaring an injected field 3.8.1
3.8 Initializer methods 3.9
3.8.1 Declaring an initializer method 3.9.1
3.8.2 Initializer method parameters 3.9.2
3.9 The default binding at injection points 3.10 The default
qualifier at injection points
- 3.11 The qualifier
@Named at injection points
3.10 Beans with the @New binding 3.12 Beans with the
@New qualifier
4.3.2 Most specialized enabled bean for a bean (removed)
4.3.3 Inconsistent specialization (removed)
5.2 Policy enablement 5.2 Alternative
selection
5.2.1 Declaring
selected alternatives for a
bean
deployment archive
5.2.2 Enabled and
disabled beans
5.2.3 Inconsistent
specialization
6.4.3 Dependent pseudo-scope and Unified EL (removed)
11.3.6 Obtaining the most specialized bean (removed)
11.3.7 Obtaining a passivation capable bean by 11.3.6
identifier
11.3.8 Resolving an ambiguous dependency 11.3.7
11.3.9 Validating a dependency 11.3.8
11.3.10 Firing an event 11.3.9
11.3.11 Observer method resolution 11.3.10
11.3.12 Decorator resolution 11.3.11
11.3.13 Interceptor resolution 11.3.12
11.3.14 Determining if an annotation is a binding 11.3.13
type, scope type, stereotype or
interceptor binding type
11.3.15 Obtaining the active Context for a scope 11.3.14
11.3.16 Obtaining the ELResolver 11.3.15
- 11.3.16 Wrapping a
Unified EL ExpressionFactory
15 years, 3 months
Re: [webbeans-dev] Lifecycle for WebBeans SE Module
by Peter Royle
>> I would do this inside the SE bootstrap code, as this is a
>> requirement that is only applicable to the SE case (other container
>> provide a mechanism for this such as the contextInitialized event
>> in Servlet).
>
> OK fair dos.
>
>> Are you concerned about portability between CDI implementations or
>> between types of app (SE -> Servlet -> EE)?
>
> I was thinking not so much of portability of code between the types
> of app, more just a single way to do it for all of the types. But I
> can also see how the presence of an alternative to those standard
> ways of doing things could be considered a bad thing.
>
> Portability between implementations would be ideal, but I'm not too
> bothered about it if you guys aren't. Also I think the aim is still
> that Web Beans SE itself will be portable in this sense anyway.
>
>
>
>>
>> On 23 Sep 2009, at 05:47, Peter Royle wrote:
>>
>>> Hi,
>>>
>>> So does anyone think it might be generally useful to add a simple
>>> lifecycle event which fires once the contexts are active and can be
>>> observed by regular CDI beans? This would simplify the use case of
>>> performing application-specific, non-cdi-extending startup events
>>> (ie:
>>> _NOT_ things like registering new kinds of beans or injection
>>> points),
>>> while allowing the observing method to take full advantage of all
>>> the
>>> features of CDI.
>>>
>>> Also, obviously, it would give the SE module its portable startup
>>> hook
>>> back.
>>>
>>> Or is there already a reason why this isn't such a good idea?
>>>
>>> Cheers
>>>
>>> Pete.
>>>
>>>
>>> On Tue, 2009-09-22 at 20:53 -0400, Gavin King wrote:
>>>> On Tue, Sep 22, 2009 at 8:38 PM, Peter Royle
>>>> <howardmoon(a)screamingcoder.com> wrote:
>>>>
>>>>> Related question: How is application code written for CDI
>>>>> supposed to
>>>>> execute code on startup - does it have to register an Extension
>>>>> and
>>>>> execute without any contexts/injection?
>>>>
>>>> Yes, the solution for startup-time instantiation of objects is to
>>>> make
>>>> them Extensions.
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> webbeans-dev mailing list
>>> webbeans-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>
>
15 years, 3 months
[webbeans-dev] Lifecycle for WebBeans SE Module
by Peter Royle
Hi,
I've come across a bit of a problem with the PFD2 from the SE module
perspective. There's no longer any suitable built-in event which can
be used to kick off the SE application, due to there not being any
lifecycle events which fire while the contexts are active. We used to
use @Observes @Deployed Manager, and by doing so the observer method
was executed inside a fully injected bean with all contexts available.
In PFD2 we have the AfterDeploymentValidation event, but it gets fired
'before creating contexts and processing requests'. Then the next
lifecycle event after that is BeforeShutdown.
The simplest alternative I can think of is a custom event introduced
for WebBeans SE specifically, thrown by the SE module itself, which
isn't ideal because we lose that portability.
Any thoughts or advice?
Related question: How is application code written for CDI supposed to
execute code on startup - does it have to register an Extension and
execute without any contexts/injection?
Cheers,
Pete.
15 years, 3 months
[webbeans-dev] Can't observe built-in events
by Peter Royle
Hi,
I'm noticing that I can't successfully observe the
AfterDeploymentValidation event which is a key requirement for the SE
module. I'm not sure if this is a problem with the SE module, or with
WebBeans in general. I've tried stepping through the code and it seems
like the observers are registered, but then when the event is fired
it's like there are no observers to notify. Custom events work fine
though.
Does anyone know if built-in events should be working or of any
existing tests or sample apps I could try out to verify if the problem
lies with WB core?
Alternatively, would anyone be able to take a quick look at my
specific problem for me by doing this:
svn co https://svn.jboss.org/repos/webbeans/extensions/trunk/se
mvn clean install
You'll notice the resulting test failure:
at org.jboss.webbeans.environment.se.test.StartMainTest.testObservers
(StartMainTest.java:96)
Thanks in advance to anyone that can help.
Pete.
15 years, 3 months
[webbeans-dev] Observing BeforeBeanDiscovery
by Peter Royle
Hi,
I want to be able to observe the BeforeBeanDiscovery event, and am
unsure how to get around the obvious bootstrap problem. I'm thinking
I'll need to programatically register the observing bean (before
bootstrap.startInitialization() get's called), but I'm unsure how to
do that. Alternatively is there a better idiom for observing
BeforeBeanDiscovery?
Cheers,
Pete.
15 years, 3 months
Re: [webbeans-dev] Is @Named qualifier?
by Sven Linstaedt
quoted from the OWB dev list:
>From my point of view this is a conceptual mismatch: One spec uses the
annotation just for binding specific beans to a literal name, the other one
uses it for differentiate between multiple beans.
Even this should be no immediate issue for JSR 299's typesafe resolution
mechanism, if a single bean is further qualified with specific @Named name,
I do not feel well, if people are going to use this annotation as a
qualifying one like @Named("stage_test") on multiple beans. The EL namespace
gets polluted with unresolvable names and developers become potentially
confused by the ambiguous usage of the annotation.
In brief: Identifiers (like EL names or Spring bean IDs) does not feel like
being qualifiers (e.g. @Asynchronous) from my point of view.
br, Sven
> Reusing it for defining the EL name does make sense semantically to
> me. In general qualifiers are used in resolution, in the "by name"
> case, we have a special qualifier.
15 years, 3 months
Re: [webbeans-dev] Is @Named qualifier?
by Dan Allen
My question was retorical. I don't get how it is a qualifier. It violates
the whole type-safety approach. Having an EL name is orthogonal to having a
qualifier.
- Dan Allen
Sent from my Android-powered G1 phone:
An open platform for carriers, developers
and consumers.
On Sep 4, 2009 1:48 PM, "Mark Struberg" <struberg(a)yahoo.de> wrote:
apparently yes:
http://atinject.googlecode.com/svn/trunk/src/javax/inject/Named.java
LieGrue,
strub
--- On Fri, 9/4/09, Dan Allen <dan.j.allen(a)gmail.com> wrote:
> From: Dan Allen <dan.j.allen(a)gmail.com>
> Subject: Re: [webbeans-dev] Is @Named qualifier?
> To: "Mark Struberg" <struberg(a)yahoo.de>
> Cc: "Takeshi Kondo" <takeshi.kondo(a)gmail.com>,
webbeans-dev(a)lists.jboss.org
> Date: Friday, September 4, 2009, 6:36 PM
> @Named is a qualifier in 330? That makes > absolutely no sense. I think
that linkage should be > s...
15 years, 3 months
