myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hank Ibell (JIRA)" <>
Subject [jira] [Updated] (MYFACES-4030) MyFaces CDI support is disabled if non-CDI application is loaded first
Date Fri, 05 Feb 2016 18:41:39 GMT


Hank Ibell updated MYFACES-4030:
    Status: Patch Available  (was: Open)

> MyFaces CDI support is disabled if non-CDI application is loaded first
> ----------------------------------------------------------------------
>                 Key: MYFACES-4030
>                 URL:
>             Project: MyFaces Core
>          Issue Type: Bug
>    Affects Versions: 2.2.10-SNAPSHOT
>         Environment: WebSphere Liberty, Weld 2.3, MyFaces 2.2.8
>            Reporter: Hank Ibell
>            Priority: Minor
> If MyFaces 2.2 is loaded at the server level, MyFaces CDI support is set once per server.
This causes CDI-enabled JSF applications to not work properly if a non-CDI application is
loaded first.
> {panel:title=Steps to reproduce the error on WebSphere Liberty|bgColor=#e8e8e8}
> 1. Enable the jsf-2.2 and cdi-1.2 features on the WebSphere Liberty server.
> 2. Deploy two JSF applications: one that uses CDI (e.g. a flow built using FlowBuilder)
and one that does not use CDI.
> 3. Make a request to the non-CDI application first. The message 'MyFaces CDI support
disabled' should be written to the logs.
> 4. Make a request to the CDI-enabled application. If testing an application with a flow
built using FlowBuilder, the flow will not be discovered.
> {panel}
> I've investigated the issue and found that MyFaces has two conditions to determine CDI
> 1. CDI must be found on the classpath
> 2. The application map must have a bean manager instance
> (Found inside org.apache.myfaces.util.ExternalSpecifications#isCDIAvailable()).
> When MyFaces is shared between different applications, basing CDI availability on an
application's configuration (condition two) is an issue.

This message was sent by Atlassian JIRA

View raw message