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?