Thanks Martin! We are trying to do what you suggested, however I need a way to easily identify a JavaEE component? I don't want to go through all classes to process them. I need to filter out non-JavaEE component classes as you have handled them.

The one solution I can think of is to build a static list but it is very urgly.

The following EE7 spec has made EE component classes very similar to CDI beans:
Per the CDI specification, dependency injection is supported on managed beans. There are currently three ways for a class to become a managed bean:
1.Being an EJB session bean component.
2.Being annotated with the ManagedBean annotation.
3.Satisfying the conditions described in the CDI specification.
Classes that satisfy at least one of these conditions will be eligible for full dependency injection support as described in the CDI specification.
Component classes listed in Table EE.5-1 that satisfy the third condition above, but neither the first nor the second condition, can also be used as CDI managed beans if they are annotated with a CDI bean-defining annotation or contained in a bean archive for which CDI is enabled. However, if they are used as CDI managed beans (e.g., injected into other managed classes), the instances that are managed by CDI may not be the instances that are managed by the Java EE container.

Thanks
Emily

On Mon, May 18, 2015 at 12:38 PM, Martin Kouba <mkouba@redhat.com> wrote:
I think you should create an InjectionTarget upfront, during EE component initialization (i.e. cache the IT for a component,
similarly to how javax.enterprise.inject.spi.Unmanaged works) and before an EE component instance is instantiated.

Martin

Dne 18.5.2015 v 11:38 Emily Jiang napsal(a):
Thank you Martin! I did an experiment with your suggestion. The
org.jboss.weld.manager.api.WeldManager.createInjectionTargetBuilder(AnnotatedType<T>)
for EE components was called by us when an EE component class is
instanciated so it is too late for the validation (I think this api is
used for creating instances or I was wrong, please explain a bit more).
The validation has to happen during weld  WeldBootstrap.validateBeans(),
so an DefinitionException should cause the deployment failure.

On Mon, May 18, 2015 at 9:02 AM, Martin Kouba <mkouba@redhat.com
<mailto:mkouba@redhat.com>> wrote:

    Emily,

    I've looked at WildFly integration code and it makes use of
    org.jboss.weld.manager.api.WeldManager.createInjectionTargetBuilder(AnnotatedType<T>)
    for EE components, i.e. delegates validation to weld implemetation.

    M

    Dne 18.5.2015 v 09:51 Emily Jiang napsal(a):

        oops. yes. Can you shed some lights on this problem?

        On Mon, May 18, 2015 at 8:48 AM, Martin Kouba <mkouba@redhat.com
        <mailto:mkouba@redhat.com>
        <mailto:mkouba@redhat.com <mailto:mkouba@redhat.com>>> wrote:

             Emily,

             I believe this one belongs rather to the weld-dev ML.

             Martin

             Dne 18.5.2015 v 09:23 Emily Jiang napsal(a):


                 In CDI1.2 spec, section 5.5.7
                 If a Java EE component class supporting injection that
        is not a
                 bean has
                 an injection point of
                 type InjectionPoint and qualifier @Default, the container
                 automatically
                 detects the problem
                 and treats it as a definition error.

                 How can I plugin this validation? Is there a callback
        spi I can
                 use to
                 validate the injection point on JavaEE component? This
        exception
                 needs
                 to be thrown during the application deployment.

                 --
                 Thanks
                 Emily
                 =================
                 Emily Jiang
        ejiang@apache.org <mailto:ejiang@apache.org>
        <mailto:ejiang@apache.org <mailto:ejiang@apache.org>>
                 <mailto:ejiang@apache.org <mailto:ejiang@apache.org>
        <mailto:ejiang@apache.org <mailto:ejiang@apache.org>>>





        --
        Thanks
        Emily
        =================
        Emily Jiang
        ejiang@apache.org <mailto:ejiang@apache.org>
        <mailto:ejiang@apache.org <mailto:ejiang@apache.org>>


    --
    Martin Kouba
    Software Engineer
    Red Hat, Czech Republic




--
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org <mailto:ejiang@apache.org>

--
Martin Kouba
Software Engineer
Red Hat, Czech Republic



--
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org