Uploaded image for project: 'OpenWebBeans'
  1. OpenWebBeans
  2. OWB-894

OpenWebBeansJsfPlugin logs "skipped deployment" on all @FacesComponent classes with an UndeclaredThrowableException

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.1
    • Fix Version/s: 1.2.2
    • Component/s: None
    • Labels:
      None

      Description

      Deployment of a project with JSF utility library OmniFaces (https://code.google.com/p/omnifaces/) on TomEE 1.6.0 SNAPSHOT results in the following log, whereby all @FacesComponent annotated classes are been validated as managed beans:

      INFO: Adding OpenWebBeansPlugin : [OpenWebBeansJsfPlugin]
      aug 21, 2013 3:31:57 PM org.apache.webbeans.config.BeansDeployer isValidManagedBean
      INFO: skipped deployment of: org.omnifaces.component.tree.TreeNodeItem reason: java.lang.reflect.UndeclaredThrowableException
      aug 21, 2013 3:31:57 PM org.apache.webbeans.config.BeansDeployer isValidManagedBean
      INFO: skipped deployment of: org.omnifaces.component.output.OutputFormat reason: java.lang.reflect.UndeclaredThrowableException
      aug 21, 2013 3:31:57 PM org.apache.webbeans.config.BeansDeployer isValidManagedBean
      INFO: skipped deployment of: org.omnifaces.component.tree.TreeNode reason: java.lang.reflect.UndeclaredThrowableException
      aug 21, 2013 3:31:57 PM org.apache.webbeans.config.BeansDeployer isValidManagedBean
      INFO: skipped deployment of: org.omnifaces.component.validator.ValidateAllOrNone reason: java.lang.reflect.UndeclaredThrowableException
      [etc...]

      This is wrong in 2 ways:

      1. Why are @FacesComponent classes validated as managed beans in first place? They are nowhere in OmniFaces registered as managed beans.
      2. The UndeclaredThrowableException in reason is unhelpful. It is hiding the real reason.

        Activity

        Hide
        struberg Mark Struberg added a comment -

        Hi Bauke! If those classes are in a jar which has a META-INF/beans.xml and qualify for a CDI bean then we have to scan them as per the CDI spec. Is there a sample somewhere how your scanned class looks like?

        Show
        struberg Mark Struberg added a comment - Hi Bauke! If those classes are in a jar which has a META-INF/beans.xml and qualify for a CDI bean then we have to scan them as per the CDI spec. Is there a sample somewhere how your scanned class looks like?
        Hide
        balusc Bauke Scholtz added a comment -

        Hi, the simplest example look like this:

        package com.example.component;
        
        import javax.faces.component.FacesComponent;
        import javax.faces.component.UIComponentBase;
        
        @FacesComponent("com.example.MyComponentType")
        public class MyComponent extends UIComponentBase {
        
            @Override
            public String getFamily() {
                return "com.example.MyComponentFamily";
            }
        
        }
        
        Show
        balusc Bauke Scholtz added a comment - Hi, the simplest example look like this: package com.example.component; import javax.faces.component.FacesComponent; import javax.faces.component.UIComponentBase; @FacesComponent( "com.example.MyComponentType" ) public class MyComponent extends UIComponentBase { @Override public String getFamily() { return "com.example.MyComponentFamily" ; } }
        Hide
        balusc Bauke Scholtz added a comment -

        FYI, for the time being, we successfully bypassed those logs by creating a CDI extension which invokes ProcessAnnotatedType#veto() on those classes. See also: https://code.google.com/p/omnifaces/source/browse/src/org/omnifaces/VetoAnnotatedTypeExtension.java This way OWB won't bother to validate them as managed beans.

        Show
        balusc Bauke Scholtz added a comment - FYI, for the time being, we successfully bypassed those logs by creating a CDI extension which invokes ProcessAnnotatedType#veto() on those classes. See also: https://code.google.com/p/omnifaces/source/browse/src/org/omnifaces/VetoAnnotatedTypeExtension.java This way OWB won't bother to validate them as managed beans.
        Hide
        smithh032772 Howard W. Smith, Jr. added a comment -

        @BalusC, interesting. i wonder if this is in OmniFaces 1.6 or 1.6.1 or latest (omnifaces) snapshot available for download. I currently have OmniFaces 1.6, did not download 1.6.1 since i'm not deploying omnifaces in EAR (with multiple WARs), but i may be downloading 1.6.1, today/ASAP, just so i have latest version of omnifaces.

        Show
        smithh032772 Howard W. Smith, Jr. added a comment - @BalusC, interesting. i wonder if this is in OmniFaces 1.6 or 1.6.1 or latest (omnifaces) snapshot available for download. I currently have OmniFaces 1.6, did not download 1.6.1 since i'm not deploying omnifaces in EAR (with multiple WARs), but i may be downloading 1.6.1, today/ASAP, just so i have latest version of omnifaces.
        Hide
        smithh032772 Howard W. Smith, Jr. added a comment -

        I downloaded and added OmniFaces 1.6.1 to my project/app, and I see that OmniFaces 1.6.1 does what you stated above.

        Show
        smithh032772 Howard W. Smith, Jr. added a comment - I downloaded and added OmniFaces 1.6.1 to my project/app, and I see that OmniFaces 1.6.1 does what you stated above.
        Hide
        struberg Mark Struberg added a comment -

        is there a small sample project on github which I can try?

        Show
        struberg Mark Struberg added a comment - is there a small sample project on github which I can try?
        Hide
        markoc50 Martin Kočí added a comment -

        @Mark, you can see this misleading INFO + reason: java.lang.reflect.UndeclaredThrowableException with deltaSpike 0.5 with JSF-modul:

        INFO: skipped deployment of: org.apache.deltaspike.jsf.impl.component.window.WindowIdHolderComponent reason: java.lang.reflect.UndeclaredThrowableException

        reason is (not in the log):

        Caused by: org.apache.webbeans.exception.WebBeansConfigurationException: Bean implementation class : org.apache.deltaspike.jsf.impl.component.window.WindowIdHolderComponent can not implement JSF UIComponent
        at org.apache.webbeans.jsf.plugin.OpenWebBeansJsfPlugin.isManagedBean(OpenWebBeansJsfPlugin.java:34)
        ... 28 more

        The check (IComponent.class.isAssignableFrom(clazz) = "not a CDI Bean" is 100% correct but the Implementation with a expcetion is not reasonable. Exceptions are really for exceptional states and this one is a simple validation. I would suggest something like:

        public List<ConstraintVialotion> isManagedBean( Class<?> clazz ) throws WebBeansConfigurationException
        {
        if (UIComponent.class.isAssignableFrom(clazz))

        { return Lists.newArrayList(new ConstraintViolation("Bean implementation class : " + clazz.getName() + " can not implement JSF UIComponent")); }

        }
        or something like that.

        OWB produce similar INFO by myfaces 2.2 deployment:
        INFO: skipped deployment of: org.apache.myfaces.flow.cdi.FlowScopeCDIExtension reason: Bean implementation class can not implement javax.enterprise.inject.spi.Extension.!
        Reason (not in the log):
        org.apache.webbeans.exception.WebBeansConfigurationException: Bean implementation class can not implement javax.enterprise.inject.spi.Extension.!
        at org.apache.webbeans.util.WebBeansUtil.checkManagedBean(WebBeansUtil.java:286)
        at org.apache.webbeans.config.BeansDeployer.isValidManagedBean(BeansDeployer.java:657)

        Again, I think this is no exeptional state, the combination a CDI-Archive with a javax.enterprise.inject.spi.Extension-implementation is pretty normal

        Show
        markoc50 Martin Kočí added a comment - @Mark, you can see this misleading INFO + reason: java.lang.reflect.UndeclaredThrowableException with deltaSpike 0.5 with JSF-modul: INFO: skipped deployment of: org.apache.deltaspike.jsf.impl.component.window.WindowIdHolderComponent reason: java.lang.reflect.UndeclaredThrowableException reason is (not in the log): Caused by: org.apache.webbeans.exception.WebBeansConfigurationException: Bean implementation class : org.apache.deltaspike.jsf.impl.component.window.WindowIdHolderComponent can not implement JSF UIComponent at org.apache.webbeans.jsf.plugin.OpenWebBeansJsfPlugin.isManagedBean(OpenWebBeansJsfPlugin.java:34) ... 28 more The check (IComponent.class.isAssignableFrom(clazz) = "not a CDI Bean" is 100% correct but the Implementation with a expcetion is not reasonable. Exceptions are really for exceptional states and this one is a simple validation. I would suggest something like: public List<ConstraintVialotion> isManagedBean( Class<?> clazz ) throws WebBeansConfigurationException { if (UIComponent.class.isAssignableFrom(clazz)) { return Lists.newArrayList(new ConstraintViolation("Bean implementation class : " + clazz.getName() + " can not implement JSF UIComponent")); } } or something like that. OWB produce similar INFO by myfaces 2.2 deployment: INFO: skipped deployment of: org.apache.myfaces.flow.cdi.FlowScopeCDIExtension reason: Bean implementation class can not implement javax.enterprise.inject.spi.Extension.! Reason (not in the log): org.apache.webbeans.exception.WebBeansConfigurationException: Bean implementation class can not implement javax.enterprise.inject.spi.Extension.! at org.apache.webbeans.util.WebBeansUtil.checkManagedBean(WebBeansUtil.java:286) at org.apache.webbeans.config.BeansDeployer.isValidManagedBean(BeansDeployer.java:657) Again, I think this is no exeptional state, the combination a CDI-Archive with a javax.enterprise.inject.spi.Extension-implementation is pretty normal
        Hide
        struberg Mark Struberg added a comment -

        Oh darn, I finally found the reason why we have this in our code. This is code which was required by an old version of the spec (webbeans-20081029.pdf). Back then it did have the following wording (which is now long time gone):

        3.2.1. Which Java classes are simple Web Beans?
        A top-level Java class is a simple Web Bean if it meets the following conditions:
        ...
        It does not extend javax.faces.component.UIComponent. ...

        Gonna remove the code which restricts this.

        Show
        struberg Mark Struberg added a comment - Oh darn, I finally found the reason why we have this in our code. This is code which was required by an old version of the spec (webbeans-20081029.pdf). Back then it did have the following wording (which is now long time gone): 3.2.1. Which Java classes are simple Web Beans? A top-level Java class is a simple Web Bean if it meets the following conditions: ... It does not extend javax.faces.component.UIComponent. ... Gonna remove the code which restricts this.
        Hide
        struberg Mark Struberg added a comment -

        Should all be fixed now. Can you please test and report back if it did work?

        Show
        struberg Mark Struberg added a comment - Should all be fixed now. Can you please test and report back if it did work?
        Hide
        smithh032772 Howard W. Smith, Jr. added a comment -

        CONFIRMED/verified the fix for you. please see below.

        1. Prior to your fix, Mark, this issue occurred while using OmniFaces '1.6' and tomee+ 2013-Oct-05
        2. Earlier (my previous comment), I learned that this issue is fixed when using OmniFaces '1.6.1' and tomee+ 2013-Oct-05
        3. Today, I did the following:

        a. Downloaded tomee+ 2013-Oct-10, which includes the following OWB files:

        C:\apache-tomee-plus-1.6.0-SNAPSHOT\lib>dir /b openwebbeans*.jar
        openwebbeans-ee-1.2.1-20131009.155420-54.jar
        openwebbeans-ee-common-1.2.1-20131009.155420-54.jar
        openwebbeans-ejb-1.2.1-20131009.155420-54.jar
        openwebbeans-el22-1.2.1-20131009.155420-54.jar
        openwebbeans-impl-1.2.1-20131009.155420-55.jar
        openwebbeans-jsf-1.2.1-20131009.155420-54.jar
        openwebbeans-spi-1.2.1-20131009.155420-54.jar
        openwebbeans-web-1.2.1-20131009.155420-54.jar

        b. Modified my project libs/classpath to use OmniFaces 1.6
        c. deployed WAR to tomee+, started tomee+, and the following is in the log (which shows that it is fixed):

        Oct 10, 2013 1:14:20 AM org.apache.openejb.cdi.OpenEJBLifecycle startApplication
        INFO: OpenWebBeans Container is starting...
        Oct 10, 2013 1:14:20 AM org.apache.webbeans.plugins.PluginLoader startUp
        INFO: Adding OpenWebBeansPlugin : [CdiPlugin]
        Oct 10, 2013 1:14:20 AM org.apache.webbeans.plugins.PluginLoader startUp
        INFO: Adding OpenWebBeansPlugin : [OpenWebBeansJsfPlugin]
        Oct 10, 2013 1:14:23 AM org.apache.webbeans.config.BeansDeployer validateInjectionPoints
        INFO: All injection points were validated successfully.

        4. Earlier, when I was running scenario mentioned in #1 (above), this issue still persisted; see log below:

        <snip>

        Oct 05, 2013 1:32:13 AM org.apache.openejb.cdi.OpenEJBLifecycle startApplication
        INFO: OpenWebBeans Container is starting...
        Oct 05, 2013 1:32:13 AM org.apache.webbeans.plugins.PluginLoader startUp
        INFO: Adding OpenWebBeansPlugin : [CdiPlugin]
        Oct 05, 2013 1:32:13 AM org.apache.webbeans.plugins.PluginLoader startUp
        INFO: Adding OpenWebBeansPlugin : [OpenWebBeansJsfPlugin]
        Oct 05, 2013 1:32:14 AM org.apache.webbeans.config.BeansDeployer isValidManagedBean
        INFO: skipped deployment of: org.omnifaces.component.validator.ValidateOrder reason: java.lang.reflect.UndeclaredThrowableException
        Oct 05, 2013 1:32:14 AM org.apache.webbeans.config.BeansDeployer isValidManagedBean
        INFO: skipped deployment of: org.omnifaces.component.validator.ValidateAll reason: java.lang.reflect.UndeclaredThrowableException

        </snip>

        Per everything I mentioned above, this issue is definitely fixed or does not occur with previous versions of OmniFaces (which includes OmniFaces 1.6).

        Show
        smithh032772 Howard W. Smith, Jr. added a comment - CONFIRMED/verified the fix for you. please see below. 1. Prior to your fix, Mark, this issue occurred while using OmniFaces '1.6' and tomee+ 2013-Oct-05 2. Earlier (my previous comment), I learned that this issue is fixed when using OmniFaces '1.6.1' and tomee+ 2013-Oct-05 3. Today, I did the following: a. Downloaded tomee+ 2013-Oct-10, which includes the following OWB files: C:\apache-tomee-plus-1.6.0-SNAPSHOT\lib>dir /b openwebbeans*.jar openwebbeans-ee-1.2.1-20131009.155420-54.jar openwebbeans-ee-common-1.2.1-20131009.155420-54.jar openwebbeans-ejb-1.2.1-20131009.155420-54.jar openwebbeans-el22-1.2.1-20131009.155420-54.jar openwebbeans-impl-1.2.1-20131009.155420-55.jar openwebbeans-jsf-1.2.1-20131009.155420-54.jar openwebbeans-spi-1.2.1-20131009.155420-54.jar openwebbeans-web-1.2.1-20131009.155420-54.jar b. Modified my project libs/classpath to use OmniFaces 1.6 c. deployed WAR to tomee+, started tomee+, and the following is in the log (which shows that it is fixed): Oct 10, 2013 1:14:20 AM org.apache.openejb.cdi.OpenEJBLifecycle startApplication INFO: OpenWebBeans Container is starting... Oct 10, 2013 1:14:20 AM org.apache.webbeans.plugins.PluginLoader startUp INFO: Adding OpenWebBeansPlugin : [CdiPlugin] Oct 10, 2013 1:14:20 AM org.apache.webbeans.plugins.PluginLoader startUp INFO: Adding OpenWebBeansPlugin : [OpenWebBeansJsfPlugin] Oct 10, 2013 1:14:23 AM org.apache.webbeans.config.BeansDeployer validateInjectionPoints INFO: All injection points were validated successfully. 4. Earlier, when I was running scenario mentioned in #1 (above), this issue still persisted; see log below: <snip> Oct 05, 2013 1:32:13 AM org.apache.openejb.cdi.OpenEJBLifecycle startApplication INFO: OpenWebBeans Container is starting... Oct 05, 2013 1:32:13 AM org.apache.webbeans.plugins.PluginLoader startUp INFO: Adding OpenWebBeansPlugin : [CdiPlugin] Oct 05, 2013 1:32:13 AM org.apache.webbeans.plugins.PluginLoader startUp INFO: Adding OpenWebBeansPlugin : [OpenWebBeansJsfPlugin] Oct 05, 2013 1:32:14 AM org.apache.webbeans.config.BeansDeployer isValidManagedBean INFO: skipped deployment of: org.omnifaces.component.validator.ValidateOrder reason: java.lang.reflect.UndeclaredThrowableException Oct 05, 2013 1:32:14 AM org.apache.webbeans.config.BeansDeployer isValidManagedBean INFO: skipped deployment of: org.omnifaces.component.validator.ValidateAll reason: java.lang.reflect.UndeclaredThrowableException </snip> Per everything I mentioned above, this issue is definitely fixed or does not occur with previous versions of OmniFaces (which includes OmniFaces 1.6).
        Hide
        struberg Mark Struberg added a comment -

        txs for verifying

        Show
        struberg Mark Struberg added a comment - txs for verifying

          People

          • Assignee:
            Unassigned
            Reporter:
            balusc Bauke Scholtz
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development