On Mon, Oct 19, 2009 at 1:58 PM, Roberto Chinnici
<Roberto.Chinnici@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.