[weld-dev] [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New

[Gavin King]

On Mon, Oct 19, 2009 at 1:58 PM, Roberto Chinnici
<Roberto.Chinnici at 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 at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org