Extending DateTimeConverter breaks f:convertDateTime in Omnifaces 2.6 #368

Closed
rharerhare opened this Issue Mar 30, 2017 · 4 comments

Comments

Projects
None yet
2 participants
@rharerhare

I have a @FacesConverter which extends DateTimeConverter:


@FacesConverter(value="localDateConverter")
public class LocalDateConverter extends DateTimeConverter implements Converter {

    @Override
    public String getAsString(FacesContext context, UIComponent component, Object modelValue) {
    	if (modelValue == null) {
            return "";
        }

    	setType("date");

    	if (modelValue instanceof LocalDate) {
        	setType("date");
        	return super.getAsString(context, component, 
        			Date.from(((LocalDate) modelValue).atStartOfDay(ZoneId.systemDefault()).toInstant()));
        } else {
            throw new ConverterException(new FacesMessage(modelValue + " is not a valid LocalDate"));
        }
    }
    
    @Override
    public Object getAsObject(FacesContext context, UIComponent component, String submittedValue) {
    	if (submittedValue == null || submittedValue.isEmpty()) {
            return null;
        }
    	
    	setType("date");
    	Object o = super.getAsObject(context, component, submittedValue);

        if (o instanceof Date) {
        	// See: https://stackoverflow.com/questions/33066904/localdate-to-java-util-date-and-vice-versa-simpliest-conversion
        	Instant instant = ((Date) o).toInstant();
        	
        	// Note: Since we are only dealing with Dates, we can ignore time.
        	return instant.atOffset(ZoneOffset.UTC).toLocalDate();
        } else {
            throw new ConverterException(new FacesMessage(submittedValue + " is not a valid LocalDate"));
        }
    }
}

I reference it using:
<o:converter converterId="localDateConverter" pattern="EEEE, MMMM d, yyyy"/>

this works fine, however, after upgrading from Omnifaces 2.5.1 to 2.6.1, using the normal converter:

<h:outputText value="#{business.created}">
    <f:convertDateTime type="both" pattern="dd-MM-yy HH:mm:ss" />
</h:outputText>

now breaks. I get a message that the object is not a LocalDate. It appears that my converter is now called when using <f:convertDateTime>. Here is a abbreviated stack trace:

javax.servlet.ServletException: javax.faces.convert.ConverterException: 2017-03-06 15:31:20.0 is not a valid LocalDate
	at org.omnifaces.filter.FacesExceptionFilter.doFilter(FacesExceptionFilter.java:105)
	at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:108)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
	at org.omnifaces.filter.CacheControlFilter.doFilter(CacheControlFilter.java:239)
	at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:108)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
	....
Caused by: javax.faces.convert.ConverterException: 2017-03-06 15:31:20.0 is not a valid LocalDate
	at com.smr.horae.jsfconverter.LocalDateConverter.getAsString(LocalDateConverter.java:41)
	at com.smr.horae.jsfconverter.PCalendarLocalDateConverter.getAsString(PCalendarLocalDateConverter.java:21)
	at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.getFormattedValue(HtmlBasicRenderer.java:521)

I have tested with exactly the same code, with the only difference being Omnifaces 2.6.1 versus 2.5.1.

I should note, that another class PCalendarLocalDateConverter extends LocalDateConverter above. One other change that had to be made from 2.5.1 to 2.6.1 was putting @Specializes on the PCalendarLocalDateConverter otherwise I get the AmbiguousResolutionException. Not sure if that is somehow related.

@BalusC

This comment has been minimized.

Show comment
Hide comment
@BalusC

BalusC Mar 30, 2017

Member

Is this WildFly 8? Differently put, which Mojarra version?

The workaround would be to compose DateTimeConverter instead of inherit from it.

Member

BalusC commented Mar 30, 2017

Is this WildFly 8? Differently put, which Mojarra version?

The workaround would be to compose DateTimeConverter instead of inherit from it.

@rharerhare

This comment has been minimized.

Show comment
Hide comment
@rharerhare

rharerhare Mar 30, 2017

This is Wildfly 10.1.0.Final , so Mojarra 2.2. I also just discovered the "@Specializes" I had to add, causes things to break when using 2.5.1, not positive but the formatting of dates using the "localDateConverter" I think is happening with the "PCalendarLocalDateConverter" in the following scenario:

<h:outputText value="#{payment.date}">
    <o:converter converterId="localDateConverter" pattern="MMM" />
</h:outputText><br/>

If I take out the @Specializes, everything starts to work again.

Did the way the converters get instantiated change to using CDI from something else? It kind of seems like the converter is being picked as if it was a forClass specification was used and the converterId is ignored. Not sure if this makes sense, since the converter stuff is still a bit of a black box to me.

Thanks for all the posts on stackoverflow and for Omnifaces, you have been a very valuable resource for figuring this stuff out. I will give the composition workaround a try.

rharerhare commented Mar 30, 2017

This is Wildfly 10.1.0.Final , so Mojarra 2.2. I also just discovered the "@Specializes" I had to add, causes things to break when using 2.5.1, not positive but the formatting of dates using the "localDateConverter" I think is happening with the "PCalendarLocalDateConverter" in the following scenario:

<h:outputText value="#{payment.date}">
    <o:converter converterId="localDateConverter" pattern="MMM" />
</h:outputText><br/>

If I take out the @Specializes, everything starts to work again.

Did the way the converters get instantiated change to using CDI from something else? It kind of seems like the converter is being picked as if it was a forClass specification was used and the converterId is ignored. Not sure if this makes sense, since the converter stuff is still a bit of a black box to me.

Thanks for all the posts on stackoverflow and for Omnifaces, you have been a very valuable resource for figuring this stuff out. I will give the composition workaround a try.

@BalusC

This comment has been minimized.

Show comment
Hide comment
@BalusC

BalusC Mar 31, 2017

Member

It works for me in both 2.5.1 and 2.6.1.

I only notice, when I set beans.xml to bean-discovery-mode="all" instead of bean-discovery-mode="annotated", then I get exactly the same problem in both 2.5.1 and 2.6.1.

Can you please reconfirm?

Member

BalusC commented Mar 31, 2017

It works for me in both 2.5.1 and 2.6.1.

I only notice, when I set beans.xml to bean-discovery-mode="all" instead of bean-discovery-mode="annotated", then I get exactly the same problem in both 2.5.1 and 2.6.1.

Can you please reconfirm?

@rharerhare

This comment has been minimized.

Show comment
Hide comment
@rharerhare

rharerhare Mar 31, 2017

Will confirm and try to create a smaller test case. It might take a few days since I'm a bit swamped at the moment.

rharerhare commented Mar 31, 2017

Will confirm and try to create a smaller test case. It might take a few days since I'm a bit swamped at the moment.

@BalusC BalusC closed this in d68f204 Apr 4, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment