[
https://issues.jboss.org/browse/CDI-701?page=com.atlassian.jira.plugin.sy...
]
Guillermo González de Agüero commented on CDI-701:
--------------------------------------------------
Thanks [~mkouba] for pointing me to that issue. The interesting fact is that it didn't
work on TomEE either (with OpenWebBeans). That what led me to think it was not supported
by the spec.
I was aware of the trimmed discovery mode, but I'm still relying on Java EE 7
application servers and for people like me, there's unfortunately still a journey
before we can use CDI 2. But anyway, what I'm trying to do is a library that would be
put into the classpath of a war, so I wouldn't be in control of the discovery mode of
the war itself.
Since this is required to work by the spec, could a test be added to the TCK? I understand
that would put us in a complicated situation, where the RI wouldn't pass it, but the
fact is that the absence of that test makes it difficult to know whether it's expected
to work or no (to the point that the other certified implementation doesn't work
either). Would a disabled test do the trick? It wouldn't hurt certifications, but
users looking at it (like me in this case) would be alerted that there's a bug.
Should addSterotype trigger discovery of new annotated types?
-------------------------------------------------------------
Key: CDI-701
URL:
https://issues.jboss.org/browse/CDI-701
Project: CDI Specification Issues
Issue Type: Clarification
Components: Portable Extensions
Reporter: Guillermo González de Agüero
I've tried to post this question to the mailing list multiple times without success,
so I fill an issue for it.
I'm adding some annotations as stereotypes via an extension, with the purpose of
converting into beans any classes annotated with them (JAX-RS resources in my specific
case). What I'm facing is that classes with that annotations are still only discovered
if they were to be discovered before. So when using discovery-mode="annotated",
my JAX-RS resources are not passed to the @ProcessAnnotatedType event.
WildFly automatically converts JAX-RS resources into @RequestScoped CDI beans, but
looking at the code I saw it does that dealing directly with Weld APIs at server level,
not on a portable manner at RESTEasy level.
I haven't found any mention in the spec that my approach wouldn't work, but the
TCK doesn't address this usecase, which makes me think it's not supported.
Could you please clarify me the situation? Could this me changed on a future version?
And the original email I sent:
{quote}
Hi,
I have a question about the behavior of the "BeforeBeanDiscovery#add*()"
methods.
My usecase is the following: I'd want to convert all JAX-RS resources into CDI beans.
That resources are all annotated with @Path. My understanding was that converting that
annotation into a stereotype would make them eligible as bean types.
Since I can't modify that annotation, I just created an extension that observes the
BeforeBeanDiscovery event and converts @Path into a stereotype associated with the
@RequestScoped annotation. But it doesn't work, neither on Weld nor on OpenWebBeans.
The class is not discovered on the next ProcessAnnotatedType event.
I haven't found anything in the spec that explicitly says that a "runtime
added" bean defining annotation makes clases eligible for discovery. But I think is
makes sense.
Checking the TCK, test
org.jboss.cdi.tck.tests.extensions.stereotype.StereotypeExtensionTest tests that the
addition of the stereotype works, but doesn't cover my case of adding a stereotype to
a non bean class.
Is this expected to work that way? Is a bug on the TCK and implementations? Any other way
to achieve my goal?
Regards,
Guillermo González de Agüero
{quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)