5:12 p.m.
Check out sections 2.2.2, 3.12, 3.5.2 together with the new sentence
regarding @New added to 5.7.1 and 11.3.4.
This is everything that is needed for 299 to *elegantly* pass the 330 TCK.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
7:01 p.m.
OK, one problem with this. @BeanTypes does not really read well. We
should pick something better, along the lines of @Named and friends.
Pete and I think @Typed works.
On Sat, Oct 17, 2009 at 11:12 AM, Gavin King <gavin.king(a)gmail.com> wrote:
Check out sections 2.2.2, 3.12, 3.5.2 together with the new sentence
regarding @New added to 5.7.1 and 11.3.4.
This is everything that is needed for 299 to *elegantly* pass the 330 TCK.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
6:03 p.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
Gavin King wrote:
Check out sections 2.2.2, 3.12, 3.5.2 together with the new sentence
regarding @New added to 5.7.1 and 11.3.4.
This is everything that is needed for 299 to *elegantly* pass the 330 TCK.
Can you explain again the new semantics for @New and why it is needed?
I'm reading 3.12 and I have trouble understanding how a class inside an
archive which is NOT a bean deployment archive could give rise to a
managed bean (at least in the sense of 299). It seems then that the
premise of 3.12 is empty and no second beans will ever be created. And I
don't think you meant for DriversSeat and SpareTire in your example to
be annotated with @ManagedBean, since the 330 TCK doesn't do that.
Also, I'm not sure why you excluded @New in 11.3.4. Doesn't that make
the SPI less powerful than the annotations?
--Roberto
6:56 p.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
Roberto Chinnici wrote:
Gavin King wrote:
> Check out sections 2.2.2, 3.12, 3.5.2 together with the new sentence
> regarding @New added to 5.7.1 and 11.3.4.
>
> This is everything that is needed for 299 to *elegantly* pass the 330
> TCK.
>
Can you explain again the new semantics for @New and why it is needed?
It's just a loosening of a restriction, so that the semantics of @New
can apply to a class that is not part of a bean deployment archive. The
problem is the previous approach required an additional support class
NonContextual, which was using the BeanManager to implement the behavior
of @New. With this change the user has to only a provide the simple
class with producer methods.
I'm reading 3.12 and I have trouble understanding how a class inside an
archive which is NOT a bean deployment archive could give rise to a
managed bean (at least in the sense of 299). It seems then that the
premise of 3.12 is empty and no second beans will ever be created. And I
don't think you meant for DriversSeat and SpareTire in your example to
be annotated with @ManagedBean, since the 330 TCK doesn't do that.
The thinking was that we will treat them as a managed bean definition,
since they basically are, even though they are not annotated with
@ManagedBean. Are you saying we can't do that without the TCK using
@ManagedBean on them? I was under the impression this wasn't a hard
restriction, just that some frameworks may require it.
Also, I'm not sure why you excluded @New in 11.3.4. Doesn't
that make
the SPI less powerful than the annotations?
I don't recall the reason, I will let Gavin comment on that one.
--
Jason T. Greene
JBoss, a division of Red Hat
7:58 p.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
Jason T. Greene wrote:
Roberto Chinnici wrote:
> Gavin King wrote:
>> Check out sections 2.2.2, 3.12, 3.5.2 together with the new sentence
>> regarding @New added to 5.7.1 and 11.3.4.
>>
>> This is everything that is needed for 299 to *elegantly* pass the
>> 330 TCK.
>>
>
> Can you explain again the new semantics for @New and why it is needed?
It's just a loosening of a restriction, so that the semantics of @New
can apply to a class that is not part of a bean deployment archive.
The problem is the previous approach required an additional support
class NonContextual, which was using the BeanManager to implement the
behavior of @New. With this change the user has to only a provide the
simple class with producer methods.
OK, but the issue is that the class was not already a bean, because it
was placed (deliberately, I assume) in an archive that is not a bean
deployment archive.
While I understand that the SPI is powerful enough to create a bean out
of a plain class -- after all, that's what it was created for -- I'd
rather not have an existing annotation with other legitimate
applications, like @New, be re-purposed to do that job.
>
> I'm reading 3.12 and I have trouble understanding how a class inside
> an archive which is NOT a bean deployment archive could give rise to
> a managed bean (at least in the sense of 299). It seems then that the
> premise of 3.12 is empty and no second beans will ever be created.
> And I don't think you meant for DriversSeat and SpareTire in your
> example to be annotated with @ManagedBean, since the 330 TCK doesn't
> do that.
The thinking was that we will treat them as a managed bean definition,
since they basically are, even though they are not annotated with
@ManagedBean. Are you saying we can't do that without the TCK using
@ManagedBean on them? I was under the impression this wasn't a hard
restriction, just that some frameworks may require it.
But they are not already beans. They are classes which might reasonably
have been beans *if* the developer had wanted them to be. And even if
they were managed beans thanks to the @ManagedBean annotation, since
they lie outside a bean deployment archive, they should not be directly
accessible using 299 means. So you could create an instance using JNDI
(if the bean had a name), but not with the 299 API or SPI. Now, as I
said earlier, if somebody went and did the necessary SPI calls to define
a bean for them, then yes, it would work.
> Also, I'm not sure why you excluded @New in 11.3.4.
Doesn't that make
> the SPI less powerful than the annotations?
I don't recall the reason, I will let Gavin comment on that one.
That seems to be a hint that @New shouldn't be used for this purpose.
Maybe if you could describe what NonContextual did and how it was used,
we could figure out a suitable replacement. For example, I don't think I
would object if a bunch of SPI magic was hidden behind the use of a
standard API called NonContextual, as long as there is some
justification for it.
I'm trying to recall what the code using NonContextual looked like --
wasn't NonContextual similar to Provider?
9:21 p.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
On Mon, Oct 19, 2009 at 1:58 PM, Roberto Chinnici
<Roberto.Chinnici(a)sun.com> wrote:
OK, but the issue is that the class was not already a bean, because
it was
placed (deliberately, I assume) in an archive that is not a bean deployment
archive.
It is certainly NOT true that beans placed in archives that are not
"bean deployment archives" are not beans. A class annotated
@ManagedBean or @Stateless is a bean whether or not its archive has a
beans.xml file.
While I understand that the SPI is powerful enough to create a bean
out of a
plain class -- after all, that's what it was created for -- I'd rather not
have an existing annotation with other legitimate applications, like @New,
be re-purposed to do that job.
@New has not been re-purposed even one little bit. This is precisely
what @New is supposed to be used for: getting a "new", "clean"
instance of a class inside a producer method, so that the producer
method can define its scope and qualifiers.
Really, what happened was that we discovered an unacceptable
limitation affecting @New (well, really the limitation was not
explicit, it was something the spec was unclear on). In fact, earlier
versions of JSR-299 which defined @New differently did *not* have this
limitation. It slipped through into the RI because of the lack of
clarity in the spec.
But they are not already beans.
Yes they are.
@Stateless class Foo {}
is a bean. Even if there is no beans.xml file.
@ManagedBean class Foo {}
is a bean. Even if there is no beans.xml file. Even
class Foo { @Inject Bar bar; }
will be treated by JSR-330 as a bean even if there is no beans.xml file.
They are classes which might reasonably have
been beans *if* the developer had wanted them to be.
They are classes that *are* beans, but that just happen to be deployed
in an archive that is not being scanned by the 299 implementation.
And even if they were
managed beans thanks to the @ManagedBean annotation, since they lie outside
a bean deployment archive, they should not be directly accessible using 299
means. So you could create an instance using JNDI (if the bean had a name),
but not with the 299 API or SPI.
That's not a limitation that JSR-330 imposes, and it therefore would
affect the 330 -> 299 migration scenario, as pointed out by Jim.
Again, this limitation was not there by design. Recent versions of the
spec were unclear about this issue. Earlier versions of the spec
actually were clear, and did not have the limitation.
I'm trying to recall what the code using NonContextual looked
like -- wasn't
NonContextual similar to Provider?
No. It was a workaround that called the metamodel API. Jim and I and
others all agree that 299 should not need to use the metamodel API in
order to pass the 330 TCK.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
11:37 p.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
Gavin King wrote:
On Mon, Oct 19, 2009 at 1:58 PM, Roberto Chinnici
<Roberto.Chinnici(a)sun.com> wrote:
> OK, but the issue is that the class was not already a bean, because it was
> placed (deliberately, I assume) in an archive that is not a bean deployment
> archive.
>
It is certainly NOT true that beans placed in archives that are not
"bean deployment archives" are not beans. A class annotated
@ManagedBean or @Stateless is a bean whether or not its archive has a
beans.xml file.
Of course. But neither applied to the case being discussed.
> While I understand that the SPI is powerful enough to create a
bean out of a
> plain class -- after all, that's what it was created for -- I'd rather not
> have an existing annotation with other legitimate applications, like @New,
> be re-purposed to do that job.
>
@New has not been re-purposed even one little bit. This is precisely
what @New is supposed to be used for: getting a "new", "clean"
instance of a class inside a producer method, so that the producer
method can define its scope and qualifiers.
I'm not arguing with the formulation "getting a new instance of a
class". It's when you
say "bean" instead of "class" that I start seeing some
issues/inconsistencies.
Really, what happened was that we discovered an unacceptable
limitation affecting @New (well, really the limitation was not
explicit, it was something the spec was unclear on). In fact, earlier
versions of JSR-299 which defined @New differently did *not* have this
limitation. It slipped through into the RI because of the lack of
clarity in the spec.
> But they are not already beans.
>
Yes they are.
@Stateless class Foo {}
is a bean. Even if there is no beans.xml file.
@ManagedBean class Foo {}
is a bean. Even if there is no beans.xml file.
I'm not arguing with that at all.
Even
class Foo { @Inject Bar bar; }
will be treated by JSR-330 as a bean even if there is no beans.xml file.
JSR-330 doesn't treat anything as a bean, because it only defines DI
annotations.
The platform spec (EE.5.19) says that "support for JSR-330 annotations
is conditional to their being used by a class which is part of a bean
deployment
archive". So there is a conflict.
> They are classes which might reasonably have
> been beans *if* the developer had wanted them to be.
>
They are classes that *are* beans, but that just happen to be deployed
in an archive that is not being scanned by the 299 implementation.
Well, I can tell you there is an issue. If they were managed beans, for
consistency
you should be able to use @Resource and friends with them, but I don't
think the
specs (plural) today imply that.
> And even if they were
> managed beans thanks to the @ManagedBean annotation, since they lie outside
> a bean deployment archive, they should not be directly accessible using 299
> means. So you could create an instance using JNDI (if the bean had a name),
> but not with the 299 API or SPI.
>
That's not a limitation that JSR-330 imposes, and it therefore would
affect the 330 -> 299 migration scenario, as pointed out by Jim.
JSR-330 doesn't talk about packaging at all.
Again, this limitation was not there by design. Recent versions of
the
spec were unclear about this issue. Earlier versions of the spec
actually were clear, and did not have the limitation.
> I'm trying to recall what the code using NonContextual looked like -- wasn't
> NonContextual similar to Provider?
>
No. It was a workaround that called the metamodel API. Jim and I and
others all agree that 299 should not need to use the metamodel API in
order to pass the 330 TCK.
Can you show me the code that org.jboss.weld.atinject.tck.Producers used
in its previous version,
with @BeanTypes but without @New? For some reason I can't get at it with
viewvc.jboss.org.
11:56 p.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
On 19 Oct 2009, at 22:37, Roberto Chinnici wrote:
JSR-330 doesn't treat anything as a bean, because it only defines
DI
annotations.
The platform spec (EE.5.19) says that "support for JSR-330 annotations
is conditional to their being used by a class which is part of a
bean deployment
archive". So there is a conflict.
IMO, no. EE is simply *restricting* where 299 and 330 may be used.
Given that EE consumes the 299 and 330 specs, I think this is
perfectly valid (whether it is desirable is another matter ;-). I
don't see why 299 or 330 need to also restrict themselves in this way.
Well, I can tell you there is an issue. If they were managed beans,
for consistency
you should be able to use @Resource and friends with them, but I
don't think the
specs (plural) today imply that.
The 299 states this explicitly (not implicitly).
3.12 defines which beans are new beans
Note that this second bean exists, is enabled, and is available for
injection whenever the bean class is in the application classpath,
even if the first bean is disabled, as defined by Section 5.2.2,
“Enabled and disabled beans” or is deployed out- side of a bean
deployment archive, as defined in Section 12.1, “Bean deployment
archives”, and is therefore not dis- covered during the bean
discovery process defined in Chapter 12, Packaging and deployment.
This clearly states that any class in the application class path is
represented by a new bean. As an optimisation, the implementation may
choose to only create new beans for injection points it detects with
@New specified.
So, we have established that these classes are new (managed) beans.
Now, if you look at 5.6.4, you'll see that the 299 spec requires that
Java EE component environment resources are injected into all managed
beans.
Can you show me the code that org.jboss.weld.atinject.tck.Producers
used in its previous version,
with @BeanTypes but without @New? For some reason I can't get at it
with viewvc.jboss.org.
This is a snapshot of the repo without these changes:
http://fisheye.jboss.org/browse/~date=2009-10-15T00%3A00%3A00/weld/core/t...
1:55 a.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
Pete Muir wrote:
On 19 Oct 2009, at 22:37, Roberto Chinnici wrote:
> JSR-330 doesn't treat anything as a bean, because it only defines DI
> annotations.
> The platform spec (EE.5.19) says that "support for JSR-330 annotations
> is conditional to their being used by a class which is part of a bean
> deployment
> archive". So there is a conflict.
IMO, no. EE is simply *restricting* where 299 and 330 may be used.
Given that EE consumes the 299 and 330 specs, I think this is
perfectly valid (whether it is desirable is another matter ;-). I
don't see why 299 or 330 need to also restrict themselves in this way.
We need to come up with a consistent view of how it all works together.
> Well, I can tell you there is an issue. If they were managed
beans,
> for consistency
> you should be able to use @Resource and friends with them, but I
> don't think the
> specs (plural) today imply that.
The 299 states this explicitly (not implicitly).
3.12 defines which beans are new beans
> Note that this second bean exists, is enabled, and is available for
> injection whenever the bean class is in the application classpath,
> even if the first bean is disabled, as defined by Section 5.2.2,
> “Enabled and disabled beans” or is deployed out- side of a bean
> deployment archive, as defined in Section 12.1, “Bean deployment
> archives”, and is therefore not dis- covered during the bean
> discovery process defined in Chapter 12, Packaging and deployment.
This clearly states that any class in the application class path is
represented by a new bean. As an optimisation, the implementation may
choose to only create new beans for injection points it detects with
@New specified.
But that's the issue, because it triggers scanning of all application
classes. On top of that, it's speculative scanning. If the bean isn't
discovered until we find a use of the "second bean" (with @New), should
we tentatively retain as valid all the resources the bean declares,
during scanning, only to discard them if it turns out the bean does not
actually exist (i.e. there is no usage with @New)? I'm also starting to
wonder where this process ends, given that the SPI lets the application
register new beans at runtime. Does that mean that all resources
declared anywhere are valid?
So, we have established that these classes are new (managed) beans.
Now, if you look at 5.6.4, you'll see that the 299 spec requires that
Java EE component environment resources are injected into all managed
beans.
As Jim pointed out, we were using the term "bean" differently.
1:58 a.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
On Mon, Oct 19, 2009 at 7:55 PM, Roberto Chinnici
<Roberto.Chinnici(a)sun.com> wrote:
But that's the issue, because it triggers scanning of all
application
classes.
No it doesn't! Thats the whole point!
Pete of course has implemented this without scanning of non-bean
deployment archives.
On top of that, it's speculative scanning. If the bean isn't
discovered until we find a use of the "second bean" (with @New), should we
tentatively retain as valid all the resources the bean declares, during
scanning, only to discard them if it turns out the bean does not actually
exist (i.e. there is no usage with @New)? I'm also starting to wonder where
this process ends, given that the SPI lets the application register new
beans at runtime. Does that mean that all resources declared anywhere are
valid?
Nononononono!
The 299 impl creates the Bean object for the "second bean"
(unfortunate term) when it notices the injection point with @New.
Obviously we thought this through carefully to be sure that it was
implementable.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
2:24 a.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
Gavin King wrote:
On Mon, Oct 19, 2009 at 7:55 PM, Roberto Chinnici
<Roberto.Chinnici(a)sun.com> wrote:
> But that's the issue, because it triggers scanning of all application
> classes.
>
No it doesn't! Thats the whole point!
Pete of course has implemented this without scanning of non-bean
deployment archives.
Scanning for @Resource at deployment time, not scanning for beans as such.
> On top of that, it's speculative scanning. If the bean
isn't
> discovered until we find a use of the "second bean" (with @New), should we
> tentatively retain as valid all the resources the bean declares, during
> scanning, only to discard them if it turns out the bean does not actually
> exist (i.e. there is no usage with @New)? I'm also starting to wonder where
> this process ends, given that the SPI lets the application register new
> beans at runtime. Does that mean that all resources declared anywhere are
> valid?
>
Nononononono!
The 299 impl creates the Bean object for the "second bean"
(unfortunate term) when it notices the injection point with @New.
But surely it must create the bean for the first bean too, in that it'll
show up in the metamodel.
5:20 p.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
On 20 Oct 2009, at 01:24, Roberto Chinnici wrote:
>
>
> No it doesn't! Thats the whole point!
>
> Pete of course has implemented this without scanning of non-bean
> deployment archives.
>
Scanning for @Resource at deployment time, not scanning for beans as
such.
Let's step through this, as there seems to be a lot of confusion here
(particularly around new scanning requirements):
* Something which is allowed to perform injection (such as a Java EE
component class or a managed bean *in a bean deployment archive*, so
no *new* scanning here), has an injection point which has @New on it:
@Inject @New Foo foo
where Foo is a class which exists in a module or library which is not
a bean deployment archive.
* When this injection point is registered with the 299 container, it
sees that it doesn't know about Foo as a bean already, so it creates a
new Bean object (e.g. of type NewManagedBean)
* In creating this Bean object, it scans the class for annotations on
fields, methods, constructors and parameters (this I guess is extra
scanning [1])
[1] Scanning a class like this has a very low overhead (at least in
the Sun JDK) when compared to loading class definitions for scanning
for class level annotations (such as @ManagedBean). I offered to do
some profiling on this to back up my assertion, but never got asked to
take it further. Further, an implementor is free to centralise their
scanning and thus lower their overhead further.
2:04 a.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
On Mon, Oct 19, 2009 at 7:55 PM, Roberto Chinnici
<Roberto.Chinnici(a)sun.com> wrote:
>> JSR-330 doesn't treat anything as a bean, because it only
defines DI
>> annotations.
>> The platform spec (EE.5.19) says that "support for JSR-330 annotations
>> is conditional to their being used by a class which is part of a bean
>> deployment
>> archive". So there is a conflict.
Note that section 1.2.1 of the 299 spec says:
"In the Java EE 6 environment, all component classes supporting
injection, as defined by the Java EE 6 platform specification, may
inject beans via the dependency injection service."
Also see the section 5.6 preamble, which is even more explicit.
So, yes, there is a conflict. The EE spec mentions a limitation which
299 says explicitly does not exist :-)
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
12:58 a.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
On Mon, Oct 19, 2009 at 5:37 PM, Roberto Chinnici
<Roberto.Chinnici(a)sun.com> wrote:
Gavin King wrote:
On Mon, Oct 19, 2009 at 1:58 PM, Roberto Chinnici
<Roberto.Chinnici(a)sun.com> wrote:
OK, but the issue is that the class was not already a bean, because it was
placed (deliberately, I assume) in an archive that is not a bean deployment
archive.
It is certainly NOT true that beans placed in archives that are not
"bean deployment archives" are not beans. A class annotated
@ManagedBean or @Stateless is a bean whether or not its archive has a
beans.xml file.
Of course. But neither applied to the case being discussed.
On the contrary, this "clarification" to the behavior of @New
certainly does apply to both these cases.
While I understand that the SPI is powerful enough to create a bean
out of a
plain class -- after all, that's what it was created for -- I'd rather not
have an existing annotation with other legitimate applications, like @New,
be re-purposed to do that job.
@New has not been re-purposed even one little bit. This is precisely
what @New is supposed to be used for: getting a "new", "clean"
instance of a class inside a producer method, so that the producer
method can define its scope and qualifiers.
I'm not arguing with the formulation "getting a new instance of a class".
It's when you
say "bean" instead of "class" that I start seeing some
issues/inconsistencies.
There are no inconsistencies. Chapter 3 defines what classes are
beans. Chapter 12 defines which beans get detected by classpath
scanning. There are beans which are not detected by scanning. We are
saying that you can use @Inject @New for those beans, even if you
can't inject them in any other way.
JSR-330 doesn't treat anything as a bean, because it only defines
DI
annotations.
The platform spec (EE.5.19) says that "support for JSR-330 annotations
is conditional to their being used by a class which is part of a bean
deployment
archive". So there is a conflict.
Then this clause in the platform spec is making it impossible to take
an archive that worked with Guice, and have it continue working
without change in 299.
Note that that language also means that I can't have a plain war with
servlets that use JSR-330 annotations, or a plain EJB jar with EJB
beans that use JSR-330 annotations. This was *never* what was
envisaged by the 299 spec, and we went out of our way to make sure
that things that weren't injectable by 299 could still inject using
299.
You should immediately remove that language. That's an enormous glaring error.
Well, I can tell you there is an issue. If they were managed beans,
for
consistency
you should be able to use @Resource and friends with them, but I don't think
the
specs (plural) today imply that.
* The EJB spec certainly assumes that I can use @Resource in something
that is not in a bean deployment archive.
* The JSF spec certainly allows managed beans to use @Resource when
they are deployed in something that is not a bean deployment archive.
* The 299 spec was certainly written to assume that there are things
using 330 annotations and common annotations that are deployed in
archives that are not bean deployment archives.
I'm not sure what other specs are relevant here.
i.e. I basically think you're off your rocker here :-) The specs do
collectively require this.
And even if they were
managed beans thanks to the @ManagedBean annotation, since they lie outside
a bean deployment archive, they should not be directly accessible using 299
means. So you could create an instance using JNDI (if the bean had a name),
but not with the 299 API or SPI.
You have provided no argumentation in support of "should not".
Whereas I have provided a Very Good Reason why they *should* be
injectable, with limited semantics, using the special @New annotation.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
1:40 a.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
Gavin King wrote:
On Mon, Oct 19, 2009 at 5:37 PM, Roberto Chinnici
<Roberto.Chinnici(a)sun.com> wrote:
> Gavin King wrote:
>
> On Mon, Oct 19, 2009 at 1:58 PM, Roberto Chinnici
> <Roberto.Chinnici(a)sun.com> wrote:
>
>
>
> OK, but the issue is that the class was not already a bean, because it was
> placed (deliberately, I assume) in an archive that is not a bean deployment
> archive.
>
>
> It is certainly NOT true that beans placed in archives that are not
> "bean deployment archives" are not beans. A class annotated
> @ManagedBean or @Stateless is a bean whether or not its archive has a
> beans.xml file.
>
>
> Of course. But neither applied to the case being discussed.
>
On the contrary, this "clarification" to the behavior of @New
certainly does apply to both these cases.
The case being discussed was DriversSeat and SpareTire from the 330 TCK,
i.e. the latest version of the Producers class you circulated.
> While I understand that the SPI is powerful enough to create a
bean out of a
> plain class -- after all, that's what it was created for -- I'd rather not
> have an existing annotation with other legitimate applications, like @New,
> be re-purposed to do that job.
>
>
> @New has not been re-purposed even one little bit. This is precisely
> what @New is supposed to be used for: getting a "new", "clean"
> instance of a class inside a producer method, so that the producer
> method can define its scope and qualifiers.
>
>
> I'm not arguing with the formulation "getting a new instance of a
class".
> It's when you
> say "bean" instead of "class" that I start seeing some
> issues/inconsistencies.
>
There are no inconsistencies. Chapter 3 defines what classes are
beans. Chapter 12 defines which beans get detected by classpath
scanning. There are beans which are not detected by scanning. We are
saying that you can use @Inject @New for those beans, even if you
can't inject them in any other way.
The "inconsistencies" are between the various specs that together define
requirements
for an EE container.
> JSR-330 doesn't treat anything as a bean, because it only
defines DI
> annotations.
> The platform spec (EE.5.19) says that "support for JSR-330 annotations
> is conditional to their being used by a class which is part of a bean
> deployment
> archive". So there is a conflict.
>
Then this clause in the platform spec is making it impossible to take
an archive that worked with Guice, and have it continue working
without change in 299.
Note that that language also means that I can't have a plain war with
servlets that use JSR-330 annotations, or a plain EJB jar with EJB
beans that use JSR-330 annotations.
What is a "plain war"?
"Support for JSR-330 annotations" means "support for JSR-330 annotations
by the container"
of course.
This was *never* what was
envisaged by the 299 spec, and we went out of our way to make sure
that things that weren't injectable by 299 could still inject using
299.
You should immediately remove that language. That's an enormous glaring error.
Maybe you should read that spec section, just to make sure it says what
you think it says.
> Well, I can tell you there is an issue. If they were managed
beans, for
> consistency
> you should be able to use @Resource and friends with them, but I don't think
> the
> specs (plural) today imply that.
>
* The EJB spec certainly assumes that I can use @Resource in something
that is not in a bean deployment archive.
* The JSF spec certainly allows managed beans to use @Resource when
they are deployed in something that is not a bean deployment archive.
* The 299 spec was certainly written to assume that there are things
using 330 annotations and common annotations that are deployed in
archives that are not bean deployment archives.
I'm not sure what other specs are relevant here.
i.e. I basically think you're off your rocker here :-) The specs do
collectively require this.
You are missing my point. Component classes that support injection are
listed
in the EE spec (Table EE.5-1). They are, and must be, discoverable by the
container at deployment time. Moreover, the container doesn't have to go
out of
its way to discover anything else. This is why it's important to decide
what classes
are managed beans.
With that premise, "beans" that are not discovered are not managed beans.
> And even if they were
> managed beans thanks to the @ManagedBean annotation, since they lie outside
> a bean deployment archive, they should not be directly accessible using 299
> means. So you could create an instance using JNDI (if the bean had a name),
> but not with the 299 API or SPI.
>
You have provided no argumentation in support of "should not".
Whereas I have provided a Very Good Reason why they *should* be
injectable, with limited semantics, using the special @New annotation.
OK, let me ask you a simpler question: if I have a web module, say,
without a beans.xml
descriptor, can I lookup a BeanManager in JNDI under
java:comp/BeanManager? Currently
the platform spec says you can't.
1:55 a.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
Roberto Chinnici wrote:
Gavin King wrote:
>
> You have provided no argumentation in support of "should not".
>
> Whereas I have provided a Very Good Reason why they *should* be
> injectable, with limited semantics, using the special @New annotation.
>
OK, let me ask you a simpler question: if I have a web module, say,
without a beans.xml
descriptor, can I lookup a BeanManager in JNDI under
java:comp/BeanManager? Currently
the platform spec says you can't.
Are we all talking about the same thing? Earlier you mentioned use the
term "bean" instead of "class". Are you having an issue with the
terminology, or is it the capability you have a problem with?
To be clear, when you say @New blah, the resulting bean instance belongs
to the beanmanager associated with the injection point. The "first"
instance, if it even exists, is not touched in any way by 299. So all we
are talking about is a way to reference any class that fits the rules of
a 299 bean. In other words, anything which can be a 299 bean, has a
"new" instance implicitly created. The source of that bean is not really
important, other than it has to be visible to the classloader.
--
Jason T. Greene
JBoss, a division of Red Hat
2:17 a.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
Jason T. Greene wrote:
Roberto Chinnici wrote:
> Gavin King wrote:
>>
>> You have provided no argumentation in support of "should not".
>>
>> Whereas I have provided a Very Good Reason why they *should* be
>> injectable, with limited semantics, using the special @New annotation.
>>
>
> OK, let me ask you a simpler question: if I have a web module, say,
> without a beans.xml
> descriptor, can I lookup a BeanManager in JNDI under
> java:comp/BeanManager? Currently
> the platform spec says you can't.
>
Are we all talking about the same thing? Earlier you mentioned use the
term "bean" instead of "class". Are you having an issue with the
terminology, or is it the capability you have a problem with?
To be clear, when you say @New blah, the resulting bean instance
belongs to the beanmanager associated with the injection point. The
"first" instance, if it even exists, is not touched in any way by 299.
So all we are talking about is a way to reference any class that fits
the rules of a 299 bean. In other words, anything which can be a 299
bean, has a "new" instance implicitly created. The source of that bean
is not really important, other than it has to be visible to the
classloader.
My issue is that I need to know at deployment time what components exist
in the application, so I can do the right thing wrt @Resource and friends.
The terminology is important because bean implies component. If you
called "a class that fits the rules of a 299 bean" a pre-bean, for
example, then I think I could reasonably excuse the deployment tool from
having to look at them.
2:21 a.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
I don't understand. The deployment tool already has to look at them to
see if they are annotated @ManagedBean, right?
On Mon, Oct 19, 2009 at 8:17 PM, Roberto Chinnici
<Roberto.Chinnici(a)sun.com> wrote:
Jason T. Greene wrote:
>
> Roberto Chinnici wrote:
>>
>> Gavin King wrote:
>>>
>>> You have provided no argumentation in support of "should not".
>>>
>>> Whereas I have provided a Very Good Reason why they *should* be
>>> injectable, with limited semantics, using the special @New annotation.
>>>
>>
>> OK, let me ask you a simpler question: if I have a web module, say,
>> without a beans.xml
>> descriptor, can I lookup a BeanManager in JNDI under
>> java:comp/BeanManager? Currently
>> the platform spec says you can't.
>>
>
> Are we all talking about the same thing? Earlier you mentioned use the
> term "bean" instead of "class". Are you having an issue with the
> terminology, or is it the capability you have a problem with?
>
> To be clear, when you say @New blah, the resulting bean instance belongs
> to the beanmanager associated with the injection point. The "first"
> instance, if it even exists, is not touched in any way by 299. So all we are
> talking about is a way to reference any class that fits the rules of a 299
> bean. In other words, anything which can be a 299 bean, has a "new"
instance
> implicitly created. The source of that bean is not really important, other
> than it has to be visible to the classloader.
My issue is that I need to know at deployment time what components exist in
the application, so I can do the right thing wrt @Resource and friends.
The terminology is important because bean implies component. If you called
"a class that fits the rules of a 299 bean" a pre-bean, for example, then I
think I could reasonably excuse the deployment tool from having to look at
them.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
1:56 a.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
On Mon, Oct 19, 2009 at 7:40 PM, Roberto Chinnici
<Roberto.Chinnici(a)sun.com> wrote:
Gavin King wrote:
On Mon, Oct 19, 2009 at 5:37 PM, Roberto Chinnici
<Roberto.Chinnici(a)sun.com> wrote:
Gavin King wrote:
On Mon, Oct 19, 2009 at 1:58 PM, Roberto Chinnici
<Roberto.Chinnici(a)sun.com> wrote:
OK, but the issue is that the class was not already a bean, because it was
placed (deliberately, I assume) in an archive that is not a bean deployment
archive.
It is certainly NOT true that beans placed in archives that are not
"bean deployment archives" are not beans. A class annotated
@ManagedBean or @Stateless is a bean whether or not its archive has a
beans.xml file.
Of course. But neither applied to the case being discussed.
On the contrary, this "clarification" to the behavior of @New
certainly does apply to both these cases.
The case being discussed was DriversSeat and SpareTire from the 330 TCK,
i.e. the latest version of the Producers class you circulated.
OK, so now stick @Stateful on those classes. Would you still argue
that they are not beans? I don't think you would :-)
The "inconsistencies" are between the various specs that together define
requirements
for an EE container.
From what you've told me, there is one new sentence in the EE spec
that is inconsistent with all the other specs :-)
i.e. The sentence that says you can't use 330 annotations on a class
that is not in a 299 bean deployment archive.
Note that that language also means that I can't have a plain war
with
servlets that use JSR-330 annotations, or a plain EJB jar with EJB
beans that use JSR-330 annotations.
What is a "plain war"?
A war that is not a bean deployment archive. A war with no beans.xml file.
Do you really, really want to say that you can't use JSR-330
annotations in the servlets deployed in such a war? That was *never*
what 299 envisaged.
Maybe you should read that spec section, just to make sure it says
what you
think it says.
I will take a look, but the sentence you just quoted to me looks
completely wrong.
Any servlet, EJB or managed bean should be allowed to use @Inject and
@Resource. This functionality should not depend upon the presence of
beans.xml.
You are missing my point. Component classes that support injection
are
listed
in the EE spec (Table EE.5-1). They are, and must be, discoverable by the
container at deployment time. Moreover, the container doesn't have to go out
of
its way to discover anything else. This is why it's important to decide what
classes
are managed beans.
With that premise, "beans" that are not discovered are not managed beans.
OK, well that's a different use of the word bean than in 299. In 299
beans are beans, whether they are discovered or not. I propose that
you use the phrase "discovered beans" for your concept.
So, 299 provides 2 mechanisms for discovery of a bean:
* scanning of classes in archives with beans.xml
* scanning of injection points with @New
OK, let me ask you a simpler question: if I have a web module, say,
without
a beans.xml
descriptor, can I lookup a BeanManager in JNDI under java:comp/BeanManager?
Currently
the platform spec says you can't.
That's a very good question, and one that the 299 spec does not address.
And my answer is *definitely yes*, since you should be able to inject
into "EE components supporting injection" that are deployed in that
web module, using @Inject. So there's no reason why you should not
also be able to get them via the BeanManager API.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
2:24 a.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
Gavin King wrote:
On Mon, Oct 19, 2009 at 7:40 PM, Roberto Chinnici
<Roberto.Chinnici(a)sun.com> wrote:
> Gavin King wrote:
>
> On Mon, Oct 19, 2009 at 5:37 PM, Roberto Chinnici
> <Roberto.Chinnici(a)sun.com> wrote:
>
>
> Gavin King wrote:
>
> On Mon, Oct 19, 2009 at 1:58 PM, Roberto Chinnici
> <Roberto.Chinnici(a)sun.com> wrote:
>
>
>
> OK, but the issue is that the class was not already a bean, because it was
> placed (deliberately, I assume) in an archive that is not a bean deployment
> archive.
>
>
> It is certainly NOT true that beans placed in archives that are not
> "bean deployment archives" are not beans. A class annotated
> @ManagedBean or @Stateless is a bean whether or not its archive has a
> beans.xml file.
>
>
> Of course. But neither applied to the case being discussed.
>
>
> On the contrary, this "clarification" to the behavior of @New
> certainly does apply to both these cases.
>
>
> The case being discussed was DriversSeat and SpareTire from the 330 TCK,
> i.e. the latest version of the Producers class you circulated.
>
OK, so now stick @Stateful on those classes. Would you still argue
that they are not beans? I don't think you would :-)
Of course not.
> The "inconsistencies" are between the various specs
that together define
> requirements
> for an EE container.
>
>From what you've told me, there is one new sentence in the EE spec
that is inconsistent with all the other specs :-)
i.e. The sentence that says you can't use 330 annotations on a class
that is not in a 299 bean deployment archive.
OK, so you think I should be able to use @Inject everywhere basically,
even in modules
which are not bean deployment archives. It seems OK, but it's not what
the proposal
I sent to the platform EG back in July said.
> Note that that language also means that I can't have a plain
war with
> servlets that use JSR-330 annotations, or a plain EJB jar with EJB
> beans that use JSR-330 annotations.
>
> What is a "plain war"?
>
A war that is not a bean deployment archive. A war with no beans.xml file.
Do you really, really want to say that you can't use JSR-330
annotations in the servlets deployed in such a war? That was *never*
what 299 envisaged.
Yep, we have a disconnect.
> Maybe you should read that spec section, just to make sure it
says what you
> think it says.
>
I will take a look, but the sentence you just quoted to me looks
completely wrong.
Any servlet, EJB or managed bean should be allowed to use @Inject and
@Resource. This functionality should not depend upon the presence of
beans.xml.
I understand. Let me think about the implications.
> You are missing my point. Component classes that support
injection are
> listed
> in the EE spec (Table EE.5-1). They are, and must be, discoverable by the
> container at deployment time. Moreover, the container doesn't have to go out
> of
> its way to discover anything else. This is why it's important to decide what
> classes
> are managed beans.
>
> With that premise, "beans" that are not discovered are not managed beans.
>
OK, well that's a different use of the word bean than in 299. In 299
beans are beans, whether they are discovered or not. I propose that
you use the phrase "discovered beans" for your concept.
So, 299 provides 2 mechanisms for discovery of a bean:
* scanning of classes in archives with beans.xml
* scanning of injection points with @New
The second one is more scanning than we had in mind.
> OK, let me ask you a simpler question: if I have a web module,
say, without
> a beans.xml
> descriptor, can I lookup a BeanManager in JNDI under java:comp/BeanManager?
> Currently
> the platform spec says you can't.
>
That's a very good question, and one that the 299 spec does not address.
And my answer is *definitely yes*, since you should be able to inject
into "EE components supporting injection" that are deployed in that
web module, using @Inject. So there's no reason why you should not
also be able to get them via the BeanManager API.
Yes, that is consistent with your belief we should support @Inject
everywhere.
4:12 p.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
On Mon, Oct 19, 2009 at 8:24 PM, Roberto Chinnici
<Roberto.Chinnici(a)sun.com> wrote:
So, 299 provides 2 mechanisms for discovery of a bean:
* scanning of classes in archives with beans.xml
* scanning of injection points with @New
The second one is more scanning than we had in mind.
Well, actually, the second one is not really a scan. How it works is
by recursively chasing links (injection points) annotated @New from
enabled (scanned) beans.
I think a problem we have here is that I need to slightly change the
language of 3.12 to make it sound more like the old version in 3.8 of
the first public draft. So that folks understand this "recursively
chasing injection points annotated @New" stuff. The way it reads today
sounds almost like the container has to go off and actually create all
these Bean objects for every bean in the application. It doesn't.
I think a solution would be to say (in 3.12) that this "second bean"
is enabled if and only if it is referenced by an injection point
annotated @New. Then:
* it's clear that we are not creating thousands of Bean objects for
every bean in the app
* I can remove the special treatment of @New in the def of getBeans()
and Instance.get()
Does that make people feel more comfortable?
4:13 p.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
On Tue, Oct 20, 2009 at 10:12 AM, Gavin King <gavin.king(a)gmail.com> wrote:
I think a solution would be to say (in 3.12) that this "second
bean"
is enabled if and only if it is referenced by an injection point
annotated @New. Then:
I should say:
this "second bean" is enabled if and only if it is referenced by an
injection point annotated @New of another enabled bean.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
1:15 a.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
By the way folks, I really do what to emphasize that up until quite
recent revisions of 299, the spec did explicitly require this. If you
go back to the first Public Draft, where @New is defined a little
differently, it is very clear that this is supported. We lost that
clarity when we redefined @New.
1:35 a.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
Roberto Chinnici wrote:
Can you show me the code that org.jboss.weld.atinject.tck.Producers used
in its previous version,
with @BeanTypes but without @New? For some reason I can't get at it with
viewvc.jboss.org.
It's available here:
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/weld/core/trunk/inject-tck-run...
and here:
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/weld/core/trunk/inject-tck-run...
--
Jason T. Greene
JBoss, a division of Red Hat
9:10 p.m.
New subject: [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New
What it's saying is that:
* suppose I have a class X that is deployed in an archive in the
classpath, or an EJB X that is deployed in an EJB jar
* and that archive or EJB jar does not have a beans.xml file
* then, of course, the archive or EJB jar will not get automatically
scanned for beans,
* and so, as always, I can't write @Inject X or get an X by programmatic lookup.
However, what we do now let you do is write @Inject @New X or @Inject
@New Instance<X>.
We need this in order to allow us to integrate with existing library
jars or EJB jars that were not designed for use with 299, and which
therefore don't have a beans.xml file, or don't have qualifiers or
scopes defined as annotations on the bean classes.
An example usecase for this was given by Jim: a pre-existing jar
written for use with Guice or Spring, that contains 330 annotations,
but not the bean-defining annotations needed by 299. This
change/clarification allows us to integrate these bean classes by
writing producer methods, as demonstrated by Pete's code.
Now, because these archives are not being scanned, the 299
implementation needs to identify these classes by inspecting injection
points with the @New annotation. Therefore, we won't be able to
guarantee that BeanManager.getBeans() or Instance.get() will work when
@New is passed dynamically as a method parameter. Pete and I discussed
this and both agreed that it is not a real problem. We can't think of
a usecase where you would sometimes want a normal bean instance, and
other times a @New bean instance.
On Mon, Oct 19, 2009 at 12:03 PM, Roberto Chinnici
<Roberto.Chinnici(a)sun.com> wrote:
I'm reading 3.12 and I have trouble understanding how a class
inside an
archive which is NOT a bean deployment archive could give rise to a managed
bean (at least in the sense of 299). It seems then that the premise of 3.12
is empty and no second beans will ever be created.
The 299 implementation will discover the class by looking at the
injection point with the @New annotation, and register it as a managed
bean. It's status will be just like the status of an EJB in an EJB jar
with no beans.xml file.
And I don't think you
meant for DriversSeat and SpareTire in your example to be annotated with
@ManagedBean, since the 330 TCK doesn't do that.
I have no idea what the @ManagedBean annotation is doing, it is not needed.
Also, I'm not sure why you excluded @New in 11.3.4. Doesn't
that make the
SPI less powerful than the annotations?
It's a slight limitation, but is needed, since archives which are not
bean deployment archives are not scanned at startup time.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
5324
days inactive
5327
days old
25 comments
4 participants
participants (4)
-
Gavin King -
Jason T. Greene -
Pete Muir -
Roberto Chinnici