[
http://issues.apache.org/jira/browse/MYFACES-210?page=comments#action_12357289
]
Ken Weiner commented on MYFACES-210:
------------------------------------
I have been thinking about possible ways to fix this but am left puzzled.
>From what I understand, each converter can have attributes and properties as
>specified in the faces-config.xml DTD.
For example,
<converter>
<converter-id>...</converter-id>
<converter-class>...</converter-class>
<attribute>...</attribute>
<attribute>...</attribute>
<property>...</property>
<property>...</property>
</converter>
The javax.faces.application.Application provides the following methods to add
converters:
public abstract void addConverter(String converterId, String converterClass);
public abstract void addConverter(Class targetClass, String converterClass);
In both of those, the client code can specify the converter class name, but not
an actual converter instance. Therefore there is no way to specify the
converter properties and attributes. This seems to be the reason that
org.apache.myfaces.application.ApplicationImpl has added an additional method:
public void addConverterConfiguration(String converterClassName,
org.apache.myfaces.config.impl.digester.elements.Converter configuration)
This way, when the ApplicationImpl needs to create a converter, it can
instantiate the converter according to the class name and then read the
previously injected configuration to set the properties and attributes.
The big problem here is that the FacesConfigurator uses a factory lookup to get
a hold of the Application and since JSF allows the configuration of alternative
Application implementations, the FacesConfigurator or any other class has no
"standard" way to set the configuration (according the Application contract).
Therefore, all Applications that are not ApplicationImpl's will end up with a
bunch of converters that have no opportunity to be configured.
I don't know what to do about this. One thought is to have ApplicationImpl ask
another class like FacesConfigurator for converter configuration when it is
constructed or on demand rather than relying on it being injected.
It really feels like the Application contract should have provided a way to
feed in converter configuration :(
> Undesired dependency on ApplicationImpl in FacesConfigurator
> ------------------------------------------------------------
>
> Key: MYFACES-210
> URL: http://issues.apache.org/jira/browse/MYFACES-210
> Project: MyFaces
> Type: Bug
> Components: Implementation
> Versions: 1.0.9m9
> Environment: Custom ApplicationFactory and Application Objects
> Reporter: Walter Snel
> Assignee: Martin Marinschek
> Priority: Minor
>
> Manfred's recent additions related to the configurability of Converters
> created a dependency on a particular Application implementation in the
> FacesConfigurator.
> I noticed this because I'm using a custom ApplicationFactory that returns a
> custom Facade (with augmentations) to the ApplicationImpl class.
> In this case the FacesConfigurator doesn't call the
> addConverterConfiguration. This, later on, leads to horrible nullpointer
> exceptions when any of standard converters are used. Perhaps we could
> consider using relfection instead of the current 'instanceof' mechanism to
> find out if the addConverterConfiguration() method is supported ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
