[webbeans-dev] Hierarchical Managers
by Gavin King
On the concall, we made some significant progress with the design for
hierarchical Managers. We decided to develop the following approach:
(1) web beans belonging to a child manager may have any scope
(2) each child manager has its own set of contexts (there is a
parallel context hierarchy for each scope) that "belong" to, and have
the same lifecycle as, the parent contexts
(3) therefore the web beans belonging to the child are not visible to
web beans belonging to the parent
(4) however, web beans belonging to the parent *are* visible to web
beans belonging to the child
(5) a child manager may be associated with a context by calling
Manager.setCurrent(ScopeType), and is then automagically propagated
with the context
(6) web beans belonging to the child manager may be obtained via EL
evaluation whenever the child manager is in scope, or by directly
calling a getInstance() method of the child manager
The needed API changes are as follows:
Manager {
public Manager createChild();
public void setCurrent(Class<? extends Annotation> scope);
public void validate();
}
Context {
getChild(Manager childManager);
}
There is one question remaining open:
Should it *ever* be possible to access a web bean belonging to the
child manager via a reference that was injected into a web bean
belonging to the parent manager or into some non-contextual object
such as a servlet or MDB?
For example, we might choose to support this in the case that the
child manager web bean specializes the parent manager web bean.
Bill, is this a feature that Oracle requires? If not, I'm inclined to
*not* support it in web beans 1.0.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years
[webbeans-dev] Minor rewrite
by Gavin King
I got some feedback that section 10.3.4 from the XML configuration is
difficult to read, so I've rewritten it as follows. Should not be a
semantic change.
10.3.4. Fields of a Web Bean
A field of a Web Bean is declared by a direct child element of the Web
Bean declaration. The name of the field is the same as the name of the
element.
If the Web Bean implementation class has exactly one field with the
same name as the child element, then the child element is interpreted
to represent that field.
Otherwise, if the Web Bean implementation class does not have exactly
one field with the specified name, a DefinitionException is thrown by
the Web Bean manager at initialization time.
If more than one child element of a Web Bean declaration represents
the same field of the Web Bean implementation class, a
DefinitionException is thrown by the Web Bean manager at
initialization time.
A field declaration may contain child elements. If a field declaration
has more than one direct child element, and at least one of these
elements is something other than a <value> element in the Web Beans
namespace, a DefinitionException is thrown by the Web Bean manager at
initialization time.
An element that represents a field may declare an injected field, a
producer field or a field with an initial value.
• If the element contains a child <Produces> element in the Web Beans
namespace, a producer field was declared, as defined in Section 3.5.3,
"Declaring a producer field using XML".
• If the element contains a child <value> element in the Web Beans
namespace, a field with an initial value of type Set or List was
declared, as defined in Section 10.3.5, "Field initial value
declarations".
• Otherwise, if the element has exactly one child element, an injected
field was declared, as defined in Section 3.7.2, "Declaring an
injected field using XML".
• If the element has a non-empty body, and no child elements, a field
with an initial value was declared, as defined in Section 10.3.5,
"Field initial value declarations".
• Otherwise, a DefinitionException is thrown by the Web Bean manager
at initialization time.
If a field declaration represents an injected field, the child element
is interpreted as an injection point declaration, as specified in
Section 10.6, "Injection point declarations". If the declared type is
not assignable to the Java type of the field, a DefinitionException is
thrown by the Web Bean manager at initialization time.
The API type declared in XML may be a subtype of the Java field type.
In this case, the Web Bean manager will use the
API type declared in XML when resolving the dependency.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years
[webbeans-dev] Application scope not active
by Nicklas Karlsson
9.6.3 in the 20081203 specs lists when the Application scope is active:
• The application scope is active during the service() method of any
servlet in the web application.
• The application scope is active during any Java EE web service invocation.
• The application scope is also active during any remote method
invocation of any EJB bean, during any call to an EJBtimeout method
and during message delivery to any EJB message driven bean
When is the application scope *not* active?
The specs says that "The application context is shared between all
servlet requests, web service invocations, EJB remote method
invocations,EJB timeouts and message deliveries to message driven
beans that execute within the same application". But apparently the
application context active state is not shared? I can't recall Pete's
motivation, but I recall changing the active to a ThreadLocal.
Apparently it not "always on", and the states (application scope and
others) should be flipped according to the lifecycle rules in the
specs?
---
Nik
16 years
[webbeans-dev] [XML Field Decleration]
by Gurkan Erdogdu
In the spec within the part of the "Fields of a Web Bean", it says that
"If a field declaration has more than one direct child element, and at least one of these elements is not <value> element in
the Web Beans namespace, a DefinitionException is thrown by the Web Bean manager at initialization time."
Then, is it true that the following definition is correct ? iow, can the field decleration contains both the <value> field and the injection field?
<mybean:myField>
<value>15</value>
<mybean>x.y.x.AnotherBean</mybean>
</mybean:myField>
Actually it also says that "An element that represents a field may declare an injected field, a producer field or a field with an initial value.".
is there a contradiction?
Thanks;
Gurkan
16 years, 1 month
[webbeans-dev] Web Bean discovery
by Pete Muir
I was talking to Gavin about this, and he suggested that the discovery
should be more flexible and allow selectors/restrictions to be applied
to the classes discovered (for example, only abstract classes).
I can only speak about JBoss5, but I suspect this approach is common -
JBoss allows you to attach a visitor to the deployer and allows you to
do something with classes it finds (e.g. store them in some data
structure). This happens before web apps (from the Servlet listener)
starts.
The current approach is to discover the resources needed (as defined
by the spec) and store them in a datastructure, which is available
later for querying when we boot the Web Beans RI through the
ServletListener. So, the only way I can see to be more flexible is to
add the ability to apply selectors to the WebBeanDiscovery interface,
and index the classes discovered based on selectors in the jboss-
webbeans integration library. This requires us to define the selectors
we can use. We already have:
* Modifier (for discovering abstract classes)
* TYPE annotations
are there any others we are likely to need - it is better to define
these upfront before we do a release of the WebBeanDiscovery API...
16 years, 1 month
[webbeans-dev] multi-phase transactional observers
by Gavin King
An issue that came up from the RI team was whether a transactional
observer can observe multiple phases, for example:
void doSomething(@Observes @BeforeTransactionCompletion
@AfterTransactionCompletion SomeEvent se) { ... }
I think it's a bad idea to allow this, since it breaks the model of
one observer invocation per event fired, and because there's no real
way for the observer method to distinguish between the different
phases.
So unless anyone objects, I'm going to go ahead and clarify that this
is not supported in the spec.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years, 1 month
[webbeans-dev] Producer fields proposal
by Gavin King
OK, I've finally written up the producer fields concept that we've
been discussing.
Take a look at: 3.5, 6.7, 10.4.
Let me know if you see any problems with this stuff.
Again, I don't think this is a *critical* feature to have, but I do
think it's a nice convenience and I don't see any good reason to *not*
provide it.
The only wrinkle I spotted while writing this up is that it requires
direct access to the EJB bean class by the Web Bean manager. But since
we plan to drop the pluggability requirements, I don't see how this is
a problem. EE containers can easily implement direct access to the
bean class associated a local reference.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years, 1 month
[webbeans-dev] Suggestion
by Gavin King
One thing that we could do, purely in the interest of simplifying the
spec is to
* eliminate the notion of disposal methods, and
* require that the web bean manager raise an event whenever it created
or destroys any web bean.
Then any web bean could react to creation or destruction of an object
using an observer method:
void prepareFoo(@Observes @Created @SomeBinding Foo foo) { .... }
void disposeFoo(@Observes @Destroyed @SomeBinding Foo foo) { .... }
This is not exactly semantically identical to a disposal method, since
disposal methods have the special quality that there is at most one
disposal method per producer method, whereas according to this
proposal, the number of observers of one of these events is unlimited
(which is potentially more powerful and more error-prone).
It's just an idea - something we could do that would make the spec
simpler. I don't think it's necessarily an improvement.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years, 1 month
Fwd: [webbeans-dev] Terminology
by Pete Muir
Begin forwarded message:
> From: Michael Rotatori <rotatori(a)sbcglobal.net>
> Date: 3 December 2008 14:08:19 GMT
> To: Pete Muir <pmuir(a)redhat.com>
> Subject: Re: [webbeans-dev] Terminology
> Reply-To: rotatori(a)sbcglobal.net
>
> I think it should be kept as Web Bean. LIke you said, it sounds like
> a new model. It needs to be separate from an ejb bean name.
>
> --- On Wed, 12/3/08, Pete Muir <pmuir(a)redhat.com> wrote:
> From: Pete Muir <pmuir(a)redhat.com>
> Subject: Re: [webbeans-dev] Terminology
> To: "Gavin King" <gavin(a)hibernate.org>
> Cc: "webbeans-dev(a)lists.jboss.org" <webbeans-dev(a)lists.jboss.org>,
> "Java Community Process JSR #299 Expert List" <JSR-299-EG(a)jcp.org>,
> "Scott Ferguson" <ferg(a)caucho.com>
> Date: Wednesday, December 3, 2008, 6:40 AM
>
> On 24 Nov 2008, at 13:06, Gavin King wrote:
>
> > I've had a few discussions with a certain EE vendor who is concerned
> > that the use of the "Bean" terminology sends
> the message that
> Web
> > Beans is a separate component model that competes with EJB. I don't
> > necessarily agree, but I can see why some people might get that
> > impression. Whatever: on this issue I think we should do whatever is
> > necessary to make 299 palatable to all the vendors in the space.
> >
> > So we should search for alternative terminology. Here's my
> suggestion:
> >
> > Web Bean -> injectable type
> > simple Web Bean -> injectable java class
> > enterprise Web Bean -> session bean
> > Web Bean instance -> injectable instance / instance of an injectable
> > type
>
> This seems quite fragmented to me, I guess I would go for something
> like:
>
> Web Bean -> injectable bean
> Simple Web Bean -> injectable JavaBean
> Enterprise Web Bean -> session bean
> Web Bean instance -> injectable bean instance or just bean instance
>
> This means we loose the
> proper noun (Web Bean) which I think is what
> makes it sounds more like a new model, but to me seems more consistent
> with Java terminology.
>
> >
> >
> > WDYT? Does anyone have a better suggestion? Does anyone *not* want
> to
> > make this change?
> >
> > --
> > Gavin King
> > gavin.king(a)gmail.com
> > http://in.relation.to/Bloggers/Gavin
> > http://hibernate.org
> > http://seamframework.org
> > _______________________________________________
> > webbeans-dev mailing list
> > webbeans-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/webbeans-dev
>
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev
16 years, 1 month
