messages.txt can not be found
Closed this issue · 11 comments
Hi,
I'm having a problem diagnosing an issue running the schema validator inside a Cucumber step. The code works reliably outside cucumber, either standalone or as a Scalatest. I have attached the stack trace and the code used inside the Cucumber test. I'm not sure whether anyone may have seen this issue in their experience with schema-validator.
Any help will be gratefully received.
Sorry about the file extension, github would not allow the upload of a .scala file.
Having a look through the stack trace, and the project code. I would think there is some issue relating to the loading of "messages.txt" in the context of the Cucumber project. Is there some way to include / force the inclusion of messages.txt?
As a check step, i copied the content of (validator project) messages.txt into another messages.txt that existed in the Cucumber project. This prevented the exception, but it is a "bodge". I would prefer to maintain the (validator project) messages.txt file in the cucumber project as a distinct resource bundle. I'm just trying to find a way to do this....
I've found a solution to my problem. Please close the issue. In this case it was 'pilot error'. I can only apologise.
Hi, no need to apologize. How did you solve the issue? I'm asking in case anybody else stumbles upon the problem.
Hi Edgar,
The validator framework internally references (from SchemaRefResolver) messages.txt. In the cucumber test harness that applied the JSON validation against a micro service JSON response, also used a messages.txt that was loaded by the 'ResourceBundle'. The referenced key / value could not be found.
My solution was, I copied (not sure if this is the 'optimal' way to do it), the validator framework messages.txt as messages_en.txt to the same 'resources' folder used by the Cucumber project. This cured the problem. Please feel free to suggest a better way to achieve the right result.
Thanks for the update! From the top of my head I also can't think of any other solution (except for including validator's resources as well somehow), but your solution sounds like a solid workaround for the time being. The validator should probably provide defaults without relying on its resources, hence I'm leaving this issue open.
I had a similar issue, except that my file is called "messages.properties", adding the missing keys in there solved the issue, also changing the name of the file. This is my stacktrace:
[ERROR] [09/12/2019 17:58:10.797] [coresvc-akka.actor.default-dispatcher-2] [akka.actor.ActorSystemImpl(coresvc)] Error during processing of request: 'Can't find resource for bundle java.util.PropertyResourceBundle, key err.expected.type'. Completing with 500 Internal Server Error response. To change default exception handling behavior, provide a custom ExceptionHandler. java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key err.expected.type at java.util.ResourceBundle.getObject(ResourceBundle.java:450) at java.util.ResourceBundle.getString(ResourceBundle.java:407) at com.osinka.i18n.Messages.raw(Messages.scala:30) at com.osinka.i18n.Messages.raw$(Messages.scala:28) at com.osinka.i18n.Messages$.raw(Messages.scala:38) at com.osinka.i18n.Messages.apply(Messages.scala:34) at com.osinka.i18n.Messages.apply$(Messages.scala:33) at com.osinka.i18n.Messages$.apply(Messages.scala:38) at com.eclipsesource.schema.package$SchemaTypeExtensionOps.doValidate(package.scala:108) at com.eclipsesource.schema.package$SchemaTypeExtensionOps.validate(package.scala:122) at com.eclipsesource.schema.internal.validators.ObjectValidators$.$anonfun$validateProps$3(ObjectValidators.scala:60) at scala.collection.LinearSeqOptimized.foldLeft(LinearSeqOptimized.scala:126) at scala.collection.LinearSeqOptimized.foldLeft$(LinearSeqOptimized.scala:122) at scala.collection.immutable.List.foldLeft(List.scala:89) at com.eclipsesource.schema.internal.validators.ObjectValidators$.$anonfun$validateProps$1(ObjectValidators.scala:45) at scalaz.package$ReaderWriterState$.$anonfun$apply$4(package.scala:211) at scalaz.IndexedReaderWriterStateT$$anon$10.$anonfun$getF$3(ReaderWriterStateT.scala:57) at scalaz.IndexedReaderWriterStateT.$anonfun$run$1(ReaderWriterStateT.scala:10) at scalaz.Monad.$anonfun$map$2(Monad.scala:14) at scalaz.IdInstances$$anon$1.point(Id.scala:20) at scalaz.Monad.$anonfun$map$1(Monad.scala:14) at scalaz.IdInstances$$anon$1.bind(Id.scala:22) at scalaz.Monad.map(Monad.scala:14) at scalaz.Monad.map$(Monad.scala:14) at scalaz.IdInstances$$anon$1.map(Id.scala:19) at scalaz.IndexedReaderWriterStateT.run(ReaderWriterStateT.scala:10) at scalaz.IndexedReaderWriterStateT.$anonfun$flatMap$2(ReaderWriterStateT.scala:46) at scalaz.IndexedReaderWriterStateT.$anonfun$run$1(ReaderWriterStateT.scala:10) at scalaz.Monad.$anonfun$map$2(Monad.scala:14) at scalaz.IdInstances$$anon$1.point(Id.scala:20) at scalaz.Monad.$anonfun$map$1(Monad.scala:14) at scalaz.IdInstances$$anon$1.bind(Id.scala:22) at scalaz.Monad.map(Monad.scala:14) at scalaz.Monad.map$(Monad.scala:14) at scalaz.IdInstances$$anon$1.map(Id.scala:19) at scalaz.IndexedReaderWriterStateT.run(ReaderWriterStateT.scala:10) at scalaz.IndexedReaderWriterStateT.$anonfun$flatMap$3(ReaderWriterStateT.scala:48) at scalaz.IdInstances$$anon$1.bind(Id.scala:22) at scalaz.IndexedReaderWriterStateT.$anonfun$flatMap$2(ReaderWriterStateT.scala:46) at scalaz.IndexedReaderWriterStateT.$anonfun$run$1(ReaderWriterStateT.scala:10) at scalaz.Monad.$anonfun$map$2(Monad.scala:14) at scalaz.IdInstances$$anon$1.point(Id.scala:20) at scalaz.Monad.$anonfun$map$1(Monad.scala:14) at scalaz.IdInstances$$anon$1.bind(Id.scala:22) at scalaz.Monad.map(Monad.scala:14) at scalaz.Monad.map$(Monad.scala:14) at scalaz.IdInstances$$anon$1.map(Id.scala:19) at scalaz.IndexedReaderWriterStateT.run(ReaderWriterStateT.scala:10) at com.eclipsesource.schema.internal.draft7.constraints.ObjectConstraints7.validate(ObjectConstraints7.scala:59) at com.eclipsesource.schema.internal.validators.DefaultValidator.validate(DefaultValidator.scala:11) at com.eclipsesource.schema.internal.validators.DefaultValidator.validate(DefaultValidator.scala:8) at com.eclipsesource.schema.package$SchemaTypeExtensionOps.validateConstraints(package.scala:131) at com.eclipsesource.schema.package$SchemaTypeExtensionOps.doValidate(package.scala:72) at com.eclipsesource.schema.package$SchemaTypeExtensionOps.validate(package.scala:122) at com.eclipsesource.schema.SchemaValidator.validate(SchemaValidator.scala:275)
@leorodriguez Thanks for letting us know, we'll try to address this issue soon, such that default error messages are used in case a messages file can't be found.
@edgarmueller It is actually falling back to any file starting with the string "messages", so the potential fix you mention would not be enough.
Using any file that starts with messages in its name is the default behaviour of https://github.com/osinka/scala-i18n, which we use for internationalizing messages. We'll likely not be able to change this behaviour soon as we are scare on resources. I have pushed a PR #145 to provide default messages in case no message resource is found and I will also update the README to point this behaviour out. Once merged I'll close this issue. I hope that's fine, otherwise we are also accepting PRs of course.
Part of 0.9.6-M1.