Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong CalendarValidatorFactory being used? #9

Open
brianlenz opened this issue Mar 7, 2017 · 2 comments
Open

Wrong CalendarValidatorFactory being used? #9

brianlenz opened this issue Mar 7, 2017 · 2 comments
Assignees
Labels

Comments

@brianlenz
Copy link

We are using iCal4J 2.0.0 with iCal4J extensions 1.0.0 (all the latest). When constructing a new Calendar object, the AbstractCalendarValidatorFactory is setting its static CalendarValidatorFactory instance to a DefaultCalendarValidatorFactory instead of the expected ExtensionsCalendarValidatorFactory, which happens to be second in the Iterator returned by ServiceLoader. Is this a bug or is there something that should be done to get the classes to load in the proper order so that the ExtensionsCalendarValidatorFactory is used? As it stands right now, we are required to use the Calendar constructor that takes the Validator in order to explicitly set the ExtensionsCalendarValidator as the validator to use. Otherwise, any Calendars that use extensions will fail validation.

FWIW, we were using iCal4J 1.0.6 and iCal4J extensions 0.9.2 previously and didn't need to do anything special to handle the extensions validation (though I see the validation framework was handled completely differently on those older versions).

Thanks for providing a great open source library!

@benfortuna
Copy link
Member

Yes it does appear to be a problem with how service loader works..

I think we'll need to fix this (for now) by loading and applying all calendar validators available. I've started work on this on ical4j branch: bugfix/validator-serviceloader

regards,
ben

@brianlenz
Copy link
Author

Awesome thank you!

@benfortuna benfortuna self-assigned this Jul 26, 2018
@benfortuna benfortuna added the bug label Jul 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants