Mule JSON validation Schema component avoid error logs - json

I'm using JSON Validation Schema component and I have notice, that it logs all the errors to the console.
I would like to avoid this error message being displayed in the console.
Even though I have chosen a special exception strategy which has catch exception strategy with JSONValidation Exception and has custom logic implemented and no loggers at all in it, I still see the following error message:
org.mule.api.MessagingException: Json content is not compliant with schema
com.github.fge.jsonschema.core.report.ListProcessingReport: failure
--- BEGIN MESSAGES ---
error: string "blah" is too long (length: 4, maximum allowed: 3)
level: "error"
schema: {"loadingURI":"file:/...}
instance: {"pointer":"/blah_blah_code"}
domain: "validation"
keyword: "maxLength"
value: "blah"
found: 4
maxLength: 3
--- END MESSAGES ---
How could I make mule omit this error message? I don't want these errors to be logged to the console.

You can set the logException attribute of the catch-exception-strategy element to false, forcing mule not to log errors to the console:
<catch-exception-strategy logException="false">

set below logger to false in log4j2.xml
<AsyncLogger name="org.mule.module.apikit.validation.RestJsonSchemaValidator" level="OFF"/>

Related

NoMessageBodyWriterFoundFailure in Neuxs 3

When I installed the Neuxs3 (the version is OSS3.38.0-01 ~ OSS3.40.0-01) and call the blob store page, I encountered unexpected 500 error message.(It look like below.)
NoMessageBodyWriterFoundFailure
The error message related with this 500 error is below.
2022-06-22 02:42:09,161+0000 WARN [qtp1036716450-96] admin org.sonatype.nexus.siesta.internal.UnexpectedExceptionMapper - (ID ff32c43e-108d-4406-ba5b-45341a9c6289) Unexpected exception: org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not find MessageBodyWriter for response object of type: java.util.ArrayList of media type: text/html;charset=UTF-8
org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not find MessageBodyWriter for response object of type: java.util.ArrayList of media type: text/html;charset=UTF-8
at org.jboss.resteasy.core.ServerResponseWriter.lambda$writeNomapResponse$2(ServerResponseWriter.java:118)
at org.jboss.resteasy.core.interception.ContainerResponseContextImpl.filter(ContainerResponseContextImpl.java:399)
at org.jboss.resteasy.core.ServerResponseWriter.executeFilters(ServerResponseWriter.java:219)
at org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:95)
at org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:69)
Is anybody have an similar experience and an solution for that metter?

SpecFlow - The argument type 'System.MarshalByRefObject' cannot be converted into parameter type 'TechTalk.SpecRun.Common.Logging.ITestLogger'

In visual studio 2019, I can build and run my specific test cases perfectly in test explorer. But I run from command line, its showing below error.
Discovered 1 tests
Thread#0: The argument type 'System.MarshalByRefObject' cannot be converted into parameter type 'TechTalk.SpecRun.Commo
Thread#1:
Thread#2:
100% (1/1) completed
Done.
TechTalk.SpecRun.Framework.SpecRunException: At least one test thread aborted. ---> System.Runtime.Remoting.RemotingException: The argument type 'System.MarshalByRefObject' cannot be converted into parameter type 'TechTalk.SpecRun.Common.Logging.ITestLogger'. ---> System.InvalidCastException: Object must implement IConvertible.
at System.Convert.ChangeType(Object value, Type conversionType, IFormatProvider provider)
at System.Runtime.Remoting.Messaging.Message.CoerceArg(Object value, Type pt)
--- End of inner exception stack trace ---
Server stack trace:
at System.Runtime.Remoting.Messaging.Message.CoerceArg(Object value, Type pt)
at System.Runtime.Remoting.Messaging.Message.CoerceArgs(MethodBase mb, Object[] args, ParameterInfo[] pi)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at TechTalk.SpecRun.Framework.ITestAssemblyExecutor.Initialize(Int32 threadId, ITestExecutionManager executionManager, IAssemblyReference assemblyReference, ITestLogger logger, String testAssemblyFullPath, String testAssemblyConfigFilePath, TestExecutionConfiguration testExecutionConfiguration)
at TechTalk.SpecRun.Framework.TestThread.InitializeTestThreadExecutor(IAssemblyReference testAssembly, ExecutionModelSettings executionModelSettings, String testTarget)
at TechTalk.SpecRun.Framework.TestThread.GetThreadExecutorFor(TestItem testItem)
at TechTalk.SpecRun.Framework.TestThread.Run(ITestExecutionManager executionManagerForRun)
at TechTalk.SpecRun.Framework.AsyncTestThreadRunner.RunSync(TestExecutionManager executionManager)
--- End of inner exception stack trace ---
Result: test framework error: At least one test thread aborted.
Total: 1
Succeeded: 0
Ignored: 0
Pending: 0
Skipped: 1
Failed: 0
version I'm using:
.NET Framework : 4.6.2
SpecFlow : 2.2.1
SpecRun.Runner : 1.6.3
SpecRun.SpecFlow : 1.6.3
SpecRun.SpecFlow.2-2-0 : 1.6.3
command:
SpecRun.exe run Default.srprofile /basefolder:C:\Development\Project\bin\Debug\Automation\TestAutomation.Specs\ /outputfolder:output /filter:"testpath:Scenario:Search+page+in+Automation"
How can I fix this issue?
It is an active SpecFlow bug: https://github.com/SpecFlowOSS/SpecFlow/issues/1443
Best regards,
PM

graphhopper GHRequest not fetching

I have a problem with this code:
GraphHopperAPI gh = new GraphHopperWeb();
gh.load("http://localhost:8989/api/route");
GHResponse ph = gh.route(new GHRequest(45.104546,7.69043,45.104546,7.69043));
It gives me this error:
2014-03-29 09:33:00,036 [main] INFO graphhopper.http.GraphHopperWeb - Full request took:0.037406, API took:0.0
Exception in thread "main" java.lang.RuntimeException: Problem while fetching path 45.104546, 7.69043->45.104546, 7.69043
at com.graphhopper.http.GraphHopperWeb.route(GraphHopperWeb.java:119)
at provaMain.main(provaMain.java:23)
Caused by: org.json.JSONException: A JSONObject text must begin with '{' at character 0
at org.json.JSONTokener.syntaxError(JSONTokener.java:410)
at org.json.JSONObject.<init>(JSONObject.java:179)
at org.json.JSONObject.<init>(JSONObject.java:402)
at com.graphhopper.http.GraphHopperWeb.route(GraphHopperWeb.java:95)
... 1 more
The documentation currently undergoes a change (moving it from wiki to source). Where did you find that snippet? Please try gh.load("http://localhost:8989/"); for the latest branch and gh.load("http://localhost:8989/api"); before.

Exception thrown by type initializer for 'Microsoft.TeamFoundation.Framework.Server.ByteArray'

Please anyone has an idea what is causing this error while checking in files on tfs:
"The type initializer for 'Microsoft.TeamFoundation.Framework.Server.ByteArray' threw an exception."
this is the stack trace from the event Viewer:
**TF53010: The following error has occurred in a Team Foundation component or extension:
Date (UTC): 4/7/2014 5:57:14 AM
Machine: TFSSRV
Application Domain: /LM/W3SVC/8080/ROOT/tfs-14-130413234339367965
Assembly: Microsoft.TeamFoundation.Framework.Server, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a; v2.0.50727
Service Host: 61e34d8a-3995-492a-b0b1-b1ca43304366 (SABIS)
Process Details:
Process Name: w3wp
Process Id: 3896
Thread Id: 4844
Account name: INTEREDLB\eghanem
Detailed Message: TF30065: An unhandled exception occurred.
Web Request Details
Url: tfssrv:8080/tfs/_tfs_resources/VersionControl/v1.0/upload.ashx [method: POST]
User Agent: Team Foundation (devenv.exe, 10.0.30319.1)
Headers: Content-Length=125836&Content-Type=multipart%2fform-data%3b+boundary%3d--------------------------8e5m2D6l5Q4h6&Accept-Language=en-US&Authorization=NTLM+TlRMTVNTUAADAAAAGAAYAIQAAABcAVwBnAAAABIAEgBYAAAADgAOAGoAAAAMAAwAeAAAAAAAAAD4AQAABYKIogYC8CMAAAAPEamXFnqofvmag9Tv7MumY0kATgBUAEUAUgBFAEQATABCAGUAZwBoAGEAbgBlAG0ASQBUAFEAQwAwADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgPJ7o8t9UpE1fWPVvOiQkwEBAAAAAAAAOSm6OSZSzwGLmc3OzEbnlAAAAAACABIASQBOAFQARQBSAEUARABMAEIAAQAMAFQARgBTAFMAUgBWAAQAJgBpAG4AdABlAHIAZQBkAGwAYgAuAHMAYQBiAGkAcwAuAG4AZQB0AAMANAB0AGYAcwBzAHIAdgAuAGkAbgB0AGUAcgBlAGQAbABiAC4AcwBhAGIAaQBzAC4AbgBlAHQABQASAHMAYQBiAGkAcwAuAG4AZQB0AAgAMAAwAAAAAAAAAAEAAAAAIAAAPo4lTXR7%2fzg5WQsBAME%2f5oXFLmv2XYbJUNBj1fLeBfkKABAAAAAAAAAAAAAAAAAAAAAAAAkAPgBIAFQAVABQAC8AdABmAHMAcwByAHYALgBpAG4AdABlAHIAZQBkAGwAYgAuAHMAYQBiAGkAcwAuAG4AZQB0AAAAAAAAAAAA&Expect=100-continue&Host=tfssrv%3a8080&User-Agent=Team+Foundation+(devenv.exe%2c+10.0.30319.1)&X-TFS-Version=1.0.0.0&X-TFS-Session=f705371b-1a30-4e4a-861c-62d652add5e3&TF-Instance=f705371b-1a30-4e4a-861c-62d652add5e3
Path: /tfs/_tfs_resources/VersionControl/v1.0/upload.ashx
Local Request: False
Host Address: 192.168.200.234
User: INTEREDLB\eghanem [authentication type: NTLM]
Exception Message: The type initializer for 'Microsoft.TeamFoundation.Framework.Server.ByteArray' threw an exception. (type TypeInitializationException)
Exception Stack Trace: at Microsoft.TeamFoundation.Framework.Server.ByteArray..ctor(Int32 sizeRequested)
at Microsoft.TeamFoundation.VersionControl.Server.UploadHandler.UploadFile(VersionControlRequestContext versionControlRequestContext, String workspaceName, String workspaceOwner, String serverItem, Byte[] hash, Stream fileStream, Int64 fileLength, Int64 compressedLength, Int64 offsetFrom, CompressionType compressionType)
at Microsoft.TeamFoundation.VersionControl.Server.TeamFoundationVersionControlService.UploadFile(TeamFoundationRequestContext requestContext, String workspaceName, String workspaceOwner, String serverItem, Byte[] hash, Stream fileStream, Int64 fileLength, Int64 compressedLength, Int64 offsetFrom, CompressionType compressionType)
at Microsoft.TeamFoundation.VersionControl.Server.UploadHandler.Execute()
Inner Exception Details:
Exception Message: Exception of type 'System.OutOfMemoryException' was thrown. (type OutOfMemoryException)
Exception Stack Trace: at Microsoft.TeamFoundation.Framework.Server.BufferPool..ctor(Int32 bufferSize, Int32 initialNumberOfEntries)
at Microsoft.TeamFoundation.Framework.Server.ByteArray..cctor()
For more information, see Help and Support Center at**
I was encountering the same issue just today. For the sake of others that may hit this page, since it's the first hit when googling the exception. I looked at the MS Social question here, but the key appears to be something in the App Tier Framework, I executed IISRESET.exe (as Administrator) on the TFS app tier server and everything started working perfectly again.

ESB Mule Client staring with xml-properties fails

I use Mule 3.x
I have a code that tests MuleClient connectivity.
This test is ok and works proper way:
public void testHello() throws Exception
{
MuleClient client = new MuleClient(muleContext);
MuleMessage result = client.send("http://127.0.0.1:8080/hello", "some data", null);
assertNotNull(result);
assertNull(result.getExceptionPayload());
assertFalse(result.getPayload() instanceof NullPayload);
//TODO Assert the correct data has been received
assertEquals("hello", result.getPayloadAsString());
}
But this tes is not ok - it fail with an connection exceptions:
public void testHello_with_Spring() throws Exception {
MuleClient client = new MuleClient("mule-config-test.xml");
client.getMuleContext().start();
//it fails here
MuleMessage result = client.send("http://127.0.0.1:8080/hello", "some data", null);
assertNotNull(result);
assertNull(result.getExceptionPayload());
assertFalse(result.getPayload() instanceof NullPayload);
//TODO Assert the correct data has been received
assertEquals("hello", result.getPayloadAsString());
}
The 'mule-config-test.xml' is used in both tests, the path for this file is ok, i checked.
This is error message I have in the end:
Exception stack is:
1. Address already in use (java.net.BindException) java.net.PlainSocketImpl:-2 (null)
2. Failed to bind to uri "http://127.0.0.1:8080/hello" (org.mule.transport.ConnectException)
org.mule.transport.tcp.TcpMessageReceiver:81
(http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/transport/ConnectException.html)
-------------------------------------------------------------------------------- Root Exception stack trace: java.net.BindException: Address already in
use at java.net.PlainSocketImpl.socketBind(Native Method) at
java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383) at
java.net.ServerSocket.bind(ServerSocket.java:328)
+ 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything)
[10-05 16:33:37] ERROR HttpConnector [main]:
org.mule.transport.ConnectException: Failed to bind to uri
"http://127.0.0.1:8080/hello" [10-05 16:33:37] ERROR ConnectNotifier
[main]: Failed to connect/reconnect: HttpConnector {
name=connector.http.mule.default lifecycle=stop this=7578a7d9
numberOfConcurrentTransactedReceivers=4
createMultipleTransactedReceivers=true connected=false
supportedProtocols=[http] serviceOverrides= } . Root Exception
was: Address already in use. Type: class java.net.BindException [10-05
16:33:37] ERROR DefaultSystemExceptionStrategy [main]: Failed to bind
to uri "http://127.0.0.1:8080/hello"
org.mule.api.lifecycle.LifecycleException: Cannot process event as
"connector.http.mule.default" is stopped
I think the problem is in what you're not showing: testHello_with_Spring() is probably executing while Mule is already running. The second Mule you're starting in it then port-conflicts with the other one.
Are testHello() and testHello_with_Spring() in the same test suite? If yes, seeing that testHello() relies on an already running Mule, I'd say that would be the cause of port conflict for testHello_with_Spring().