The Send method works with Mediator, but not the Publish method. Nothing is received by consumers.
Is that on purpose? Is it expected in a later version?
Publish should work, but I just realized that it throws a NullReferenceException if there isn't a pipe specified. That's a bug, I've found and fixed it. Issue
Related
Over HTTP and inside of Visual Studio it is working fine. However, when I attempt to hit the endpoint over HTTPS I'm seeing this error and I'm not entirely sure how to figure out the problem:
info: Microsoft.AspNetCore.Server.Kestrel[17]
Connection id "0HL36O0ESIPBQ" bad request data: "Invalid request line: <0x16><0x03><0x01><0x00><0x83><0x01><0x00><0x00><0x7F><0x03><0x01>X<0xC1><0x07><0xDC><0x9E>~Y<0x05><0x13><0xC1><0xF4>^J<0xCF><0xAB><0x11><0xC3>R[<0x87><0x1D>..."Microsoft.AspNetCore.Server.Kestrel.BadHttpRequestException: Invalid request line: <0x16><0x03><0x01><0x00><0x83><0x01><0x00><0x00><0x7F><0x03><0x01>X<0xC1><0x07><0xDC><0x9E>~Y<0x05><0x13><0xC1><0xF4>^J<0xCF><0xAB><0x11><0xC3>R[<0x87><0x1D>
Fiddler gives me this:
System.IO.IOException The handshake failed due to an unexpected packet format.
My gut tells me this has to do with moving from dotnet core 1.0.1 to 1.1.0. This was all working fine before that point, but it is equally likely I screwed something else up and I'm just not sure what! :)
I'll add to Paul's hint in the form of an answer.
The .UseHttps class is in the "Microsoft.AspNetCore.Server.Kestrel.Https" module, which can be added by searching for "usehttps" in the Package Manager UI or by adding it to your project.json file. Note that at the time of this writing, version 1.1.1 is now available for ASP.NET Core, so be sure to choose the version you need.
Not sure it will solve my problem, but perhaps it will solve the problem of someone else that reads this.
Ok. I'll answer my own question. It turns out I just needed to add .UseHttps to my WebHostBuilder in program.cs:
.UseKestrel(options =>
{
options.AddServerHeader = false;
options.UseHttps("MyPfx", "MyPassword");
})
I guess I'm a little confused how this was working previously without this but hey, it works now!
I'm trying to upload a document into filenet via CEWS, but I'm getting this error:
“The unexpected exception is chained to this exception. Message was: com.filenet.apiimpl.core.GlobalIdentity incompatible with com.filenet.apiimpl.core.RepositoryIdentity“
Our Filenet people don't seem to know what that means. They've provided working code that basically looks the same as mine (but which I can't compile directly at the moment because it references parts of their project I don't have.)
So is the GlobalIdentity something I need to pass in through the web service? If so, how? If not, where is it configured?
Ok I finally spotted my mistake.
I had incorrectly set crt.TargetSpecification.classId to the name of the repository I was trying to use rather than to the correct classId.
History:
Laravel 4.2 recently updated from 4.1 running on HHVM-stable
This exact code worked before whatever broke broke
Downgrading back to 4.1 didn't resolve
Whenever (apparently) an uncaught exception is thrown, the app crashes with:
exception 'ErrorException' with message 'Attempted to serialize unserializable builtin class Closure$;1617701371#2$9f9bb1ee4ac7330c21e327d2b7294b9c$'
in /home/forge/.../vendor/jeremeamia/SuperClosure/src/Jeremeamia/SuperClosure/SerializableClosure.php:78
It's a dickens to troubleshoot because it seems to crash during error handling, so the feedback it gives me is less than helpful.
Any idea what this is about? Am I alone with this error? Googling turns up nada and this has pretty much shut us down until I can resolve it.
Turns out that happens if you try to serialize an Exception. (In this case, outputting it via Log::error("...", [$e]). Just stringify it and all is good.
First of all let me state, that the following code example worked just fine in GF 3.0.1. The troubles started when we switched to GF 3.1.
I'm using a method
#Asynchronous
public void executeFlowStep(
#Observes(during=TransactionPhase.AFTER_COMPLETION)
ExecuteFlowStepEvent executeFlowStepEvent) {
Since the switch, whenever this should receive an ExecuteFlowStepEvent I get the following error message:
WELD-000401 Failure while notifying an observer of event [package].ExecuteFlowStepEvent
No further information or stacktrace is given.
It works if I remove the #Asynchronous annotation and the AFTER_COMPLETION attribute, of course this breaks the program as I depend on the AFTER_COMPLETION timing.
I tried to ask for help on the Weld Forums, so far to no avail, although there seem to be other people with the same problem: http://seamframework.org/Community/WeldUsers
I at least would like to know:
Is this a bug, or is this wanted. Does this imply that Weld does NOT work with Asynchronous methods/AFTER_COMPLETION attributes? Why did this work in GF 3.0.1?
Has anyone managed to make this work on GF 3.1?
According to the link you posted as a comment to your own question, this is a bug that was fixed in Wield 1.1.2 and GlassFish 3.1.2 (build 14+).
disclamer: I posted this answer to an age old question to help SO (StackOverflow) get rid of unanswered questions.
I am supporting an application that has some DWR components. Whenever there is a server error i get a javascript alert that simply says 'error'.
Does anyone know where this might be configured and if there is a way to disable this. Id rather it silently fail at whatever then do this very distracting message.
Use DWR exception handlers in the positions wherever there is a chance for run time errors.
Use try catch mechanism and printstacktrace() in catch block. It works for me!