I've a kotlin spring boot project with org.hibernate:hibernate-validator:7.0.0.Final and org.glassfish:jakarta.el:4.0.1.
For testing validation constraints I create a javax.validation.Validator, like so:
val factory = Validation.buildDefaultValidatorFactory()
validator = factory.validator
This results in the following error: HV000183: Unable to initialize 'javax.el.ExpressionFactory'. Check that you have the EL dependencies on the classpath, or use ParameterMessageInterpolator instead. Which I find strange, since I included them per the instructions: https://hibernate.org/validator/documentation/getting-started/
If I combine org.hibernate:hibernate-validator:7.0.0.Final and org.glassfish:javax.el:3.0.0 it works, but it looks like 7.0.0.Final should not be used with javax.el, but with jakarta.el, without me knowing the reason why at the moment: https://in.relation.to/2021/01/06/hibernate-validator-700-62-final-released/
Any ideas on what I need to do to use hibernate-validator v7?
Related
Our team is trying to use Moment.js in our instance, but can't seem to get it to work. Here are a couple questions we have about it:
We noticed that there is a dependency out of the box called moment-timezone-with-data-2010-2020-v0.5, is this the same as moment.js? If so, does this mean we don't need to bring in moment.js as a new dependency?
We tried using the above ootb dependency AND tried to bring in moment.js to use in a widget, and we keep getting a console error saying that moment is undefined. Can someone provide some instructions on how to correctly get either one of these dependencies to work?
If we wanted to use moment.js on a platform business rule, what do we have to do to make that happen? Are you able to access a dependency via business rule?
Thanks!
Here's how I was able to do it:
Create a Script Include with the following attributes:
script name is "moment" (it needs to have this exact name)
scope is either global or the same scope as your project (I used global)
set as client callable
Paste the code from MomentJS 2.22.1 into the script body.
To verify that you can access your Script Include, open a Background Script and run the following test code:
var calendar = moment().add(1, 'days').calendar();
gs.log("calendar test: " + calendar);
var dayCount = moment().diff('1809-02-12', 'days');
gs.log('Abraham Lincoln was born ' + dayCount + " days ago!");
To answer your question on moment-timezone-with-data-2010-2020-v0.5: no's it's not the same; here's a link to Moment Timezone which is a different library by the same organization.
As of the time of this post, 2.22.1 is the newest version that runs in ServiceNow. There are newer versions of MomentJS, but they're too new for the SN interpreter.
You can also create a UI Script with version 2.22.1.
Load the code for Moment.js into a script include and then you can call that like any other script include.
If you are going to use the timezone functions you would need to rewrite the calls to moment from the timezone javascript to use the above script include.
moment.js
On April 1st, 2022, the most recent version of moment.js to work on SNOW San Diego is 2.22.1:
https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.22.1/moment.min.js
Any version > 2.22.1 will give you the following error:
Could not save record because of a compile error: JavaScript parse error at line (1) column (37954) problem = missing name after . operator (<refname>; line 1)
moment-timezone.js
On April 1st, 2022, the most recent version of moment-timezone.js to work in SNOW San Diego is 0.5.28:
https://cdnjs.cloudflare.com/ajax/libs/moment-timezone/0.5.28/moment-timezone.min.js
Any version > 0.5.28 will give you the following error:
Could not save record because of a compile error: JavaScript parse error at line (1) column (236) problem = missing name after . operator (<refname>; line 1)
sadly you can not use momentjs on the server side in ServiceNow. Here are the installation instruction for momentjs for Rhino (the javascript interpreter SNOW uses): https://gist.github.com/UnquietCode/5614860
As you can see you would need to write new Java classes which SNOW will not allow you to do.
On the Client on the other hand you can use it, just copy paste the "Browser" implementation and include it as a global ui script: https://momentjs.com/docs/#/use-it/browser/
We are moving into Scala/SBT from a Java/Gradle stack. Our gradle builds were leveraging a task called processResources and some Ant filter thing named ReplaceTokens to dynamically replace tokens in a checked-in .properties file without actually changing the .properties file (just changing the output). The gradle task looks like:
processResources {
def whoami = System.getProperty( 'user.name' );
def hostname = InetAddress.getLocalHost().getHostName()
def buildTimestamp = new Date().format('yyyy-MM-dd HH:mm:ss z')
filter ReplaceTokens, tokens: [
"buildsig.version" : project.version,
"buildsig.classifier" : project.classifier,
"buildsig.timestamp" : buildTimestamp,
"buildsig.user" : whoami,
"buildsig.system" : hostname,
"buildsig.tag" : buildTag
]
}
This task locates all the template files in the src/main/resources directory, performs the requisite substitutions and outputs the results at build/resources/main. In other words it transforms src/main/resources/buildsig.properties from...
buildsig.version=#buildsig.version#
buildsig.classifier=#buildsig.classifier#
buildsig.timestamp=#buildsig.timestamp#
buildsig.user=#buildsig.user#
buildsig.system=#buildsig.system#
buildsig.tag=#buildsig.tag#
...to build/resources/main/buildsig.properties...
buildsig.version=1.6.5
buildsig.classifier=RELEASE
buildsig.timestamp=2013-05-06 09:46:52 PDT
buildsig.user=jenkins
buildsig.system=bobk-mbp.local
buildsig.tag=dev
Which, ultimately, finds its way into the WAR file at WEB-INF/classes/buildsig.properties. This works like a champ to record build specific information in a Properties file which gets loaded from the classpath at runtime.
What do I do in SBT to get something like this done? I'm new to Scala / SBT so please forgive me if this seems a stupid question. At the end of the day what I need is a means of pulling some information from the environment on which I build and placing that information into a properties file that is classpath loadable at runtime. Any insights you can give to help me get this done are greatly appreciated.
The sbt-buildinfo is a good option. The README shows an example of how to define custom mappings and mappings that should run on each compile. In addition to the straightforward addition of normal settings like version shown there, you want a section like this:
buildInfoKeys ++= Seq[BuildInfoKey](
"hostname" -> java.net.InetAddress.getLocalHost().getHostName(),
"whoami" -> System.getProperty("user.name"),
BuildInfoKey.action("buildTimestamp") {
java.text.DateFormat.getDateTimeInstance.format(new java.util.Date())
}
)
Would the following be what you're looking for:
sbt-editsource: An SBT plugin for editing files
sbt-editsource is a text substitution plugin for SBT 0.11.x and
greater. In a way, it’s a poor man’s sed(1), for SBT. It provides the
ability to apply line-by-line substitutions to a source text file,
producing an edited output file. It supports two kinds of edits:
Variable substitution, where ${var} is replaced by a value. sed-like
regular expression substitution.
This is from Community Plugins.
I'm playing with command model binding and I looked at the example github project and I have issues when using the dependency:
"org.scalatra" % "scalatra-data-binding" % "2.2.0-RC1"
Taking the example project code i.e.
abstract class TodosCommand[S](implicit mf: Manifest[S]) extends ModelCommand[S] with ParamsOnlyCommand
class CreateTodoCommand extends TodosCommand[Todo] {
val name: Field[String] = asType[String]("name").notBlank.minLength(3)
}
case class Todo(id: Integer, name: String, done: Boolean = false)
I am unable to compile when I use the command[CreateTodoCommand] method from the CommandSupport trait i.e.
scala: type arguments [au.com.xxx.sapi.seo.CreateTodoCommand] do not conform to method command's type parameter bounds [T <: SeoServlet.this.CommandType]
val cmd = command[CreateTodoCommand]
^
I'm not that clued up with Scala but I would assume that as ParamsOnlyCommand extends Command and there is this line in the command support trait, then there should be no issues:
type CommandType <: org.scalatra.databinding.Command
Any ideas why I am getting this issue?
Cheers, Chris.
It's very likely that the reason you're having problems is that we're still linking to an ancient example version, for which the docs no longer apply. I thought I'd caught all of the example projects in the docs and moved them into https://github.com/scalatra/scalatra-website-examples, but apparently I missed this one. Sorry for the hassle!
I'll see if I can fix this today sometime, and provide a compiling example. In the meantime, you might try updating all your Scalatra-related dependencies to the 2.2.0 release - and see if that fixes anything straight away.
The latest stable release of Scalatra is currently 2.2.1, but you'll need to be careful around commands as I remember #casualjim saying that he'd changed the way things worked to some extent between 2.2.0 and 2.2.1.
In Scalatra 2.2.1, "org.scalatra" %% "scalatra-commands" % "2.2.0" I have no issues. but I don't know scalatra-data-binding is also standalone.
In application.conf (in Play 2.0.4, sbt 0.11.3) I could use following substitutions:
app {
major = 0
minor = 1
revision = 62
date = 0127
version = ${app.major}.${app.minor}.${app.revision}.${app.date}
}
After upgrade to Play 2.1.0 and sbt 0.12.2 and using this suggestion for Build.scala,
val conf = ConfigFactory.parseFile(new File("conf/application.conf"))
I get error when I do play clean:
Caused by: com.typesafe.config.ConfigException$NotResolved: need to call resolve() on root config; tried to get value type on an unresolved substitution: ConfigSubstitution(${app.major}"."${app.minor}"."${app.revision}"."${app.date})
at com.typesafe.config.impl.ConfigSubstitution.valueType(ConfigSubstitution.java:54)
at com.typesafe.config.impl.DefaultTransformer.transform(DefaultTransformer.java:15)
at com.typesafe.config.impl.SimpleConfig.findKey(SimpleConfig.java:118)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:135)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:140)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:108)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:146)
at com.typesafe.config.impl.SimpleConfig.getString(SimpleConfig.java:188)
at ApplicationBuild$.<init>(Build.scala:12)
at ApplicationBuild$.<clinit>(Build.scala)
Based on Play Configuration documentation this kind of substitution should be supported:
Implementations must take care, however, to allow objects to refer to
paths within themselves. For example, this must work:
bar : { foo : 42,
baz : ${bar.foo}
} Here, if an implementation resolved all substitutions in bar as part of resolving the substitution ${bar.foo}, there would be a
cycle. The implementation must only resolve the foo field in bar,
rather than recursing the entire bar object.
Any ideas how to fix this?
Your syntax is correct. It seems that you actually need to call resolve() as the error message says, to resolve substitutions. I guess in 2.0.x the play framework did this and provided a config that was already resolved this way. Now that the config API is used directly it needs to be resolved manually.
Add a call to resolve() in this line:
val conf = ConfigFactory.parseFile(new File("conf/application.conf")).resolve()
AFAIK, my understanding of the doc is that you should use something like:
app {
major = 0
minor = 1
revision = 62
date = 0127
version = ${major}.${minor}.${revision}.${date}
}
I did not test it...
And maybe it worked under 2.0.4 because of a bug ?
I'm using OCMock to aid in Test Driven Development I am doing for an iPad application using Xcode. I have test code like this:
id mock = [OCMockObject mockForProtocol:#protocol(SomeProtocol)];
Vector direction = { 1.0f, 2.0f, 3.0f };
[[mock expect] setDirection:direction];
When I try to compile, I'm getting warnings and errors like this:
warning: multiple methods named 'setDirection:' found
error: sending'Vector' to parameter of incompatible type
'UISwipeGestureRecognizerDirection' (aka 'enum
UISwipeGestureRecognizerDirection')
Obviously the compiler is not able to determine what type of object the mock is supposed to be. I'm not sure how to specify that it should deal with the setDirection method from the SomeProtocol protocol instead of a setDirection method from another class.
What can be done to make a test case like this build successfully?
Qualifying the mock with a cast will eliminate the ambiguity:
[(id<SomeProtocol>)[mock expect] setDirection:direction];
For the OCMock 3 modern syntax:
id protocolMock = OCMProtocolMock(#protocol(MYProtocol));
OCMExpect([(id <MYProtocol>)protocolMock ambiguousMethod]);