On Mon, Apr 15, 2024 at 10:34 PM Roland Müller wrote:
> The class should be written as org.Sign instead of org/Sign.
>
Agreed. My point was that the O.P. wrote "org/Sign" in their Go source code
and didn't show us the command they ran interactively. There may be
multiple problems with the
The class should be written as org.Sign instead of org/Sign.
Am Dienstag, 16. April 2024 schrieb Kurtis Rader :
> On Mon, Apr 15, 2024 at 4:02 AM Shivli Srivastava
wrote:
>>
>> When I run the command on my terminal , everything works as fine but
running it using exec.Command gives Error: Could
On Mon, Apr 15, 2024 at 4:02 AM Shivli Srivastava
wrote:
> When I run the command on my terminal , everything works as fine but
> running it using exec.Command gives
>
> *Error: Could not find or load main class org.SignCaused by:
> java.lang.ClassNotFoundException: org.Sign .*
Show us the
Another possible error is not setting the CWD (cmd :=
exec.CommandComntext(); cmd.Dir = `the-dir-where-DigitalSign,jar-is`).
Tamás Gulácsi a következőt írta (2024. április 16., kedd, 6:20:50 UTC+2):
> What is the _working_ command line?
> Ain't something like ```java -cp ... -jar
What is the _working_ command line?
Ain't something like ```java -cp ... -jar DigitalSign.jar org.Sign``` ?
Shivli Srivastava a következőt írta (2024. április 15., hétfő, 13:04:28
UTC+2):
> this is my code
>
> func runCommand(ctx context.Context) (string, error) {
>
> if
Ok I got your point
Thanks for the explanation.
I also checked some other well-known HTTP servers an all of them needs to
be configured to pass he proxy protocol (nginx, envoy ) so it seams the
right way to explicit configure the webserver.
Thank you very much!
Brian Candler schrieb am
> My point is that a http server that is using the standard library always
reply with an "HTTP/1.1 400 Bad Request" when the proxy protocol is part
of the tcp package.
That's the correct response, because the request is not compliant with HTTP.
> So the net/http should just handle the http
Hi,
thanks for the answer, but thats not the point.
I think it's fine to use a library or implement something to add something
to the http layer to parse the proxy protocol.
My point is that a http server that is using the standard library always
reply with an "HTTP/1.1 400 Bad Request" when
Your answer was given here:
https://github.com/golang/go/issues/65078#issuecomment-1890419683
In other words:
- net/http handles HTTP
- go-proxyprotocol handles the proxy protocol
- you combine the two to get the behaviour you want
Orthogonal pieces which handle their own responsibilities are a
Dear Gophers,
I would like to bring to your attention.
There is an “issue” with the Go standard implementation when handling HTTP
requests that are extended by the proxy protocol v1 or v2.
While the simple HTTP server works fine with regular requests, it fails
when a proxy protocol is added.
this is my code
func runCommand(ctx context.Context) (string, error) {
if JVMFound(context.Background()) {
jarPath := "/Users/shivli.srivastava/Downloads/jars/bcmail-jdk15on-159.jar:"
+
"/Users/shivli.srivastava/Downloads/jars/bcpkix-jdk15on-155.jar:" +
I created a jar where I want to run the main function of the Sign class .
*jar tf DigitalSign.jar*
META-INF/MANIFEST.MF
org/
org/Sign.class
META-INF/
bcmail-jdk15on-1.59.jar
xml-apis-1.4.01.jar
xercesImpl-2.12.2.jar
bcutil-jdk18on-1.77.jar
bcprov-jdk18on-1.77.jar
bcpkix-jdk15on-1.55.jar
12 matches
Mail list logo
