messages.txt can not be found

[london-coder]

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.

StackTrace.txt

CucumberSnippet.scala.txt

Sorry about the file extension, github would not allow the upload of a .scala file.

[london-coder]

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?

[london-coder]

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....

[london-coder]

I've found a solution to my problem. Please close the issue. In this case it was 'pilot error'. I can only apologise.

[edgarmueller]

Hi, no need to apologize. How did you solve the issue? I'm asking in case anybody else stumbles upon the problem.

[london-coder]

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.

[edgarmueller]

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.

[leorodriguez]

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)

[edgarmueller]

@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.

[leorodriguez]

@edgarmueller It is actually falling back to any file starting with the string "messages", so the potential fix you mention would not be enough.

[edgarmueller]

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.

[edgarmueller]

Part of 0.9.6-M1.