SightlyCompilerException: BinaryOperator.strictEq - aem

Need your help in resolving below exceptions: getting below exception post migration from AEM 6.1 to AEM 6.3.
This exception occurs when trying to render/load an HTML page.
All bundles are in active state.
27.09.2017 10:15:31.272 ERROR [10.5.2.154 [1506500131064] GET /content/suninternational/properties/table-bay.html HTTP/1.1] org.apache.sling.engine.impl.SlingRequestProcessorImpl service: Uncaught SlingException
org.apache.sling.scripting.sightly.compiler.SightlyCompilerException: Operands are not of the same type: the equality operator can only be applied to String, Number and Boolean types.
at org.apache.sling.scripting.sightly.compiler.expression.nodes.BinaryOperator.strictEq(Bina ryOperator.java:238)
at org.apache.sling.scripting.sightly.apps.suninternational.components.content.flyoutCompone nt.flyoutComponent_html.render(flyoutComponent_html.java:81)
Thanks

This usually happens when you're doing an equality comparison between incompatible types (String vs. Number, Object vs. Number/String).
Judging by the provided stacktrace the issue is happening somewhere in apps/suninternational/components/content/flyoutComponent/flyoutComponent.html

Related

Dart/Flutter linter rule: the type to index a map should be the key type of map?

For example, I have Map<int, int> m;. Then I can write down m['hello'] without any compile-time error, but of course, cannot find any element at runtime. I hope it will produce an error (or warning) at compile-time or lint time.
This is a big problem in many cases. For example, when I refactor Map<A, int> m into Map<B, int> m, I want to have compile-time errors for all accesses like m[some_var_of_type_A], instead of no compile-time errors and suddenly it explodes at runtime. As another example, the de-serialized JSON is of type Map<String, ...> but the key is actually a int. So it is tempting to do var userId=42; deserializedJson[userId] but only to find errors. Actually need to do deserializedJson[userId.toString()].
You know, dart's type system is so strong (even null safe!), and I really enjoy it since it catchs a LOT of bugs at compile-time. So I hope this problem can also be addressed at compile-time.
Thanks for any suggestions!
There currently is no lint to warn about doing lookups on a Map with arguments of the wrong type. This has been requested in https://github.com/dart-lang/linter/issues/1307.
Also see https://github.com/dart-lang/sdk/issues/37392, which requests a type-checked alternative to Map.operator []. In the meantime, Dart's extension mechanism allows anyone to easily add such an alternative themselves. For example, package:basics provides a type-checked Map.get extension.
NOTE:
The original answer was wrong and has been edited to:
point out the right/better answer
explain why the original answer was wrong
Thank you #jamesdlin for pointing this out.
Better answer
As pointed by #jamesdlin in his answer, the lint rule mentioned in the question has been requested in the flutter Github issues, and not in production yet.
Original Answer (wrong but kind of related to the question)
Why it is wrong:
The question was asking about the lint rule when using an index of Map. The answer however gave the lint rule about initializing a map using the wrong index (By the wrong index, I mean different data type).
Below is the answer:
There is a lint rule for this.
For example, if you define a Map like this ->
final Map<String, String> m = {
1: 'some random value',
};
It shows an error right away and this won't compile. This is the error ->
Error: A value of type 'int' can't be assigned to a variable of type 'String'.
1: 'error because index is of type String but assigned value is of type int',
^
Error: Compilation failed.
See the official docs where this lint rule, map_key_type_not_assignable is defined.
I have tested this in dartpad and vs code. Both IDEs show this error.
There could be some issues in your IDE configuration if you're not seeing this lint error.
As for your question, there is already a lint rule for this as explained above.

Random SerializationException when calling Reliable Actor before Actor activated

We are getting random Serialization Exceptions when calling a Reliable Actor service like this:
Type: System.Runtime.Serialization.SerializationException
Message: Element 'http://schemas.microsoft.com/2003/10/Serialization/:anyType' contains data from a type that maps to the name 'urn:ServiceFabric.Communication:ServiceResponseMessageHeaders'. The deserializer has no knowledge of any type that maps to this name. Consider using a DataContractResolver if you are using DataContractSerializer or add the type corresponding to 'ServiceResponseMessageHeaders' to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding it to the list of known types passed to the serializer.
ToString: System.Runtime.Serialization.SerializationException: Element 'http://schemas.microsoft.com/2003/10/Serialization/:anyType' contains data from a type that maps to the name
After research, many say this is remoting library v1, v2 mismatch problem. However, we have the v2 remoting assembly attribute defined in all actor.interface assemblies.
[assembly: FabricTransportActorRemotingProvider(RemotingListenerVersion = RemotingListenerVersion.V2, RemotingClientVersion = RemotingClientVersion.V2)]
Also the exception doesn't happen 100% of the time; it happens completely randomly. Usually in a pattern like this:
Failed to call actor service. Throw serialization exception.
After a few retries, we see an "Actor activated" message.
Calling the actor works now.
It seems happen before the actor is activated. Why does it happen like that?

typeFromString Action throws exception-uima ruta

The below code throws the error: Action "typeFromString" is not defined.
CW{-> typeFromString("Person")};
From the documentation, I understand that 'Person' is the name of an annotation that need not be declared already using DECLARE statement and that all CW's will be marked as 'Person'. Please correct me if I'm wrong and let me know how to resolve the above error.
There are two problems:
The type function typeFromString throws an exception if the type is not defined in the typesystem of the CAS (should be fixed). Short names work if they are unambiguous.
The editor reports a false error for the type function if it is used as an implicit action. This can be avoided by using CW{-> MARK(typeFromString("Person"))};. typeFromString is not an action but a function returing a type.
DISCLAIMER: I am a developer of UIMA Ruta

FluentAssertions fails when comparing exception messages

I just updated my old project to use version 4.13.0 and there was a lot of exception validation with ComparisonMode.Substring, but ComparisonMode.Substring does not exist in the newest version. I found this that explains that:
As a result of this, I decided that as of version 2.1, the ComparisonMode is obsolete and any assertions against the exception message is treated as a case-insensitive wildcard match.
But now I get loads of failed tests with:
Expected exception message to match the equivalent of "Value of
argument 'PeriodEnd' must be greater than '01.01.0001'", but "Value
of argument 'PeriodEnd' must be greater than '01.01.0001'. Value is
'01.01.0001'.
Parameter name: PeriodEnd" does not.
string I assert with
Value of argument 'PeriodEnd' must be greater than '01.01.0001'
The one it expects
Value of argument 'PeriodEnd' must be greater than '01.01.0001'. Value is '01.01.0001'.
Parameter name: PeriodEnd
But from the "patch notes" from before it seems that it should be a wildcard, and the string I assert from is a substring of the one it really is, so why does it fail?
You still need to add the wildcard characters to the call to WithMessage, just like you did when ComparisonMode.Wildcard still existed. The rationale is explained in this post:
If you need to verify that a certain string value or exception message matches the expectation, never verify the exact message. Use wildcards to verify the specific parts that are relevant to verify that the behavior meets the expectation. It will save from unexpectingly failing tests if you decide to refine the text involved.

Fragment Evaluation Error

Can someone tell me what "Fragment evaluation error" means, or where I might look for solutions? I sometimes (but not always) get lots of these errors (without changing my code):
[error] ! Fragment evaluation error
[error] ThrowableException: Could not initialize class code.model.Post$ (FutureTask.java:138)
[error] code.model.PostSpec$$anonfun$1$$anonfun$apply$1.apply$mcZ$sp(PostSpec.scala:68)
[error] code.model.PostSpec$$anonfun$1$$anonfun$apply$1.apply(PostSpec.scala:51)
[error] code.model.PostSpec$$anonfun$1$$anonfun$apply$1.apply(PostSpec.scala:51)
Line 68 of PostSpec is the first line in the (specs2) test that references the Post model companion object:
val test4 = Post.fixJValue(toextract4).extract[Selection]
I'm using Scala 2.9.0-1.
Also: I have no idea whether it matters, but Post is a net.liftweb.mongodb.record.MongoRecord class companion object:
object Post extends Post with MongoMetaRecord[Post] { ... }
In a specs2 specification, Fragments are pieces of the specification. A Fragment can be a Text, an Example, a Step.
Some fragments, like Example and Step are meant to be executed and are supposed to catch Exceptions so that they can be marked as failures. But they won't catch Errors (except AssertionErrors). So if an Example throws an OutOfMemoryError, this will be reported as a Fragment evaluation error.
Other fragments, like Text fragments are not supposed to throw exceptions when being evaluated. If they do, you will get the same Fragment evaluation error message.
Without seeing the full specification it's hard for me to say what's happening there but I suspect that you had a non-Exception type thrown in the body of an Example. But I have more questions than answers for now:
where is test4 declared? Inside the specification body? Inside a Context case class?
since errors happen intermittently, are you sure you always have a proper mongodb context? Maybe your specification examples are being executed concurrently on the same mongo db instance?