[jira] Closed: (OWB-486) ResourceBean tries to proxy final classes before testing them for being final
[ https://issues.apache.org/jira/browse/OWB-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gurkan Erdogdu closed OWB-486. -- Resolution: Fixed Fix Version/s: 1.1.0 ResourceBean tries to proxy final classes before testing them for being final - Key: OWB-486 URL: https://issues.apache.org/jira/browse/OWB-486 Project: OpenWebBeans Issue Type: Bug Components: Core Reporter: David Jencks Assignee: Gurkan Erdogdu Fix For: 1.1.0 Attachments: OWB-486.patch When you try to proxy an unproxyiable class, OWB installs its own, unlikely-to-work javassist ProxyFactory.ClassLoaderProvider. This permanently breaks Javassist since there's no way to reinstall the default. This is silly, because its much faster to check for finality than to try to construct the proxy factory. Checking for known reasons the proxy can't be created before trying to build the proxy factory avoids this problem. Attached patch also avoids an NPE that I've run into in geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-486) ResourceBean tries to proxy final classes before testing them for being final
[ https://issues.apache.org/jira/browse/OWB-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gurkan Erdogdu updated OWB-486: --- Affects Version/s: 1.0.0 Fix Version/s: 1.0.1 ResourceBean tries to proxy final classes before testing them for being final - Key: OWB-486 URL: https://issues.apache.org/jira/browse/OWB-486 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.0.0 Reporter: David Jencks Assignee: Gurkan Erdogdu Fix For: 1.1.0, 1.0.1 Attachments: OWB-486.patch When you try to proxy an unproxyiable class, OWB installs its own, unlikely-to-work javassist ProxyFactory.ClassLoaderProvider. This permanently breaks Javassist since there's no way to reinstall the default. This is silly, because its much faster to check for finality than to try to construct the proxy factory. Checking for known reasons the proxy can't be created before trying to build the proxy factory avoids this problem. Attached patch also avoids an NPE that I've run into in geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OWB-480) Avoid a couple NPEs
[ https://issues.apache.org/jira/browse/OWB-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gurkan Erdogdu closed OWB-480. -- Resolution: Fixed Fix Version/s: 1.0.1 1.1.0 Avoid a couple NPEs --- Key: OWB-480 URL: https://issues.apache.org/jira/browse/OWB-480 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: David Jencks Assignee: Gurkan Erdogdu Fix For: 1.1.0, 1.0.1 Attachments: OWB-480.patch I've found 2 possible NPE;s: 1. in an OSGI environment, its quite possible that no openwebbeans.properties files will be located, so you get a null properties object and OpenWebBeansConfiguration will have a null Properties leading to big problems. 2. in WebContainerLifecycle, the claim that it's a jsp app by configuration might be wrong. If there's no jsp factory, no need to throw an NPE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-480) Avoid a couple NPEs
[ https://issues.apache.org/jira/browse/OWB-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gurkan Erdogdu updated OWB-480: --- Affects Version/s: 1.0.0 Avoid a couple NPEs --- Key: OWB-480 URL: https://issues.apache.org/jira/browse/OWB-480 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.1.0, 1.0.0 Reporter: David Jencks Assignee: Gurkan Erdogdu Fix For: 1.1.0, 1.0.1 Attachments: OWB-480.patch I've found 2 possible NPE;s: 1. in an OSGI environment, its quite possible that no openwebbeans.properties files will be located, so you get a null properties object and OpenWebBeansConfiguration will have a null Properties leading to big problems. 2. in WebContainerLifecycle, the claim that it's a jsp app by configuration might be wrong. If there's no jsp factory, no need to throw an NPE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OWB-481) WebBeansConfigurationListener implementing ServletContextListener is not likely to work
[ https://issues.apache.org/jira/browse/OWB-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gurkan Erdogdu closed OWB-481. -- Resolution: Won't Fix OWB provides default initializtion process using listener approach. Other container can implement its own solutions. WebBeansConfigurationListener implementing ServletContextListener is not likely to work --- Key: OWB-481 URL: https://issues.apache.org/jira/browse/OWB-481 Project: OpenWebBeans Issue Type: Bug Reporter: David Jencks Assignee: Gurkan Erdogdu Currently WebBeansConfigurationListener implements ServletContextListener and uses the contextInitialized method to initialize OWB for the web app. Given an application containing a ServletContextListener that is a web bean, this requires that 1. the OWB WebBeansConfigurationListener ServletContextListener get installed before the app's ServletContextListeners 2. the OWB WebBeansConfigurationListener have it's contextInitialized called before the servlet container instantiates the apps ServletContextListeners that are web beans. There's no way to guarantee this will happen in a compliant servlet container. (Neither happens in the geronimo tomcat integration; we could force the first to happen, but not the second). It might be possible to do the initialization in a ServletContainerInitializer since I think these get called before any application classes start getting instantiated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-480) Avoid a couple NPEs
[ https://issues.apache.org/jira/browse/OWB-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12925870#action_12925870 ] David Blevins commented on OWB-480: --- Thanks, Gurkan. FYI, I just uploaded new 1.1.0-SNAPSHOTs Avoid a couple NPEs --- Key: OWB-480 URL: https://issues.apache.org/jira/browse/OWB-480 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.1.0, 1.0.0 Reporter: David Jencks Assignee: Gurkan Erdogdu Fix For: 1.1.0, 1.0.1 Attachments: OWB-480.patch I've found 2 possible NPE;s: 1. in an OSGI environment, its quite possible that no openwebbeans.properties files will be located, so you get a null properties object and OpenWebBeansConfiguration will have a null Properties leading to big problems. 2. in WebContainerLifecycle, the claim that it's a jsp app by configuration might be wrong. If there's no jsp factory, no need to throw an NPE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-487) Section 5.5.7 restrictions on injecting InjectionPoint not enforced
[ https://issues.apache.org/jira/browse/OWB-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated OWB-487: - Attachment: OWB-487.patch I'm not sure I completely understand the spec but this patch does get the test to pass in geronimo/owb. What does qualifier @Default mean? that @Default is one of the qualifiers (as my patch implements) or that it is the only qualifier (which wont work since in the tck test there's also @Any on the MANAGED bean) Section 5.5.7 restrictions on injecting InjectionPoint not enforced --- Key: OWB-487 URL: https://issues.apache.org/jira/browse/OWB-487 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: David Jencks Assignee: Gurkan Erdogdu Attachments: OWB-487.patch Section 5.5.7 ends with a couple restrictions on injecting InjectionPoint. Theres a tck test for one of them, an InjectionPoint in a servlet is not OK. text: f a bean that declares any scope other than @Dependent has an injection point of type InjectionPoint and qualifier @Default, the container automatically detects the problem and treats it as a definition error. 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. test: org.jboss.jsr299.tck.tests.lookup.injectionpoint.broken.not.bean.InjectionPointTest org.jboss.jsr299.tck.tests.lookup.injectionpoint.broken.not.bean.TestServlet_Broken -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-487) Section 5.5.7 restrictions on injecting InjectionPoint not enforced
[ https://issues.apache.org/jira/browse/OWB-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12926028#action_12926028 ] Eric Covener commented on OWB-487: -- I think this is best read as ... qualifiers @Default, @Any, and no other qualifiers which really means when the dependency will be satisfied by the containers built-in injection point. Section 5.5.7 restrictions on injecting InjectionPoint not enforced --- Key: OWB-487 URL: https://issues.apache.org/jira/browse/OWB-487 Project: OpenWebBeans Issue Type: Bug Components: Core Affects Versions: 1.1.0 Reporter: David Jencks Assignee: Gurkan Erdogdu Attachments: OWB-487.patch Section 5.5.7 ends with a couple restrictions on injecting InjectionPoint. Theres a tck test for one of them, an InjectionPoint in a servlet is not OK. text: f a bean that declares any scope other than @Dependent has an injection point of type InjectionPoint and qualifier @Default, the container automatically detects the problem and treats it as a definition error. 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. test: org.jboss.jsr299.tck.tests.lookup.injectionpoint.broken.not.bean.InjectionPointTest org.jboss.jsr299.tck.tests.lookup.injectionpoint.broken.not.bean.TestServlet_Broken -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.