Weblogic: how can I see what servlet and filters the request is processed by? - servlets

Good day!
I have a weblogic server and an enterprise application with lots of servlets and filters. I add my servlet (in fact, it is jersey-servlet) but requests that I send to my servlet are caught by something else and I have a 404 error.
So, is there a way (may be using weblogic console) how to see which filter are applied to the request and what servlet process it?

You can use a Java profiler to trace the request inside the Weblogic server.
Just attach the profiler to the Weblogic server, enable instrumentation and run your request. You will see the code path it is going through.
Btw. 404 error means Not found, so you should verify that your servlet is correctly deployed on the server

Related

How to diagnose a HTTP request being services by the wrong servlet in Wildfly?

My underlying issue is: A HTTP request gets serviced by the default servlet instead of the one I'm expecting.
Logging gives me information like this during server start
WFLYUT0021: Registered web context: /some/path
and still, curl -i http://localhost/some/path doesn't end up in my servlet, but returns HTTP 302, redirecting to /some/path/, which then gets served by Undertow's DefaultServlet. So how would I diagnose this type of issue?
Is there a way to see all deployed servlets in a Wildfly with their deployment info?
Is the Admin Console any good and if so, how?

Unknown Error on Remote Server

I have a web api running on a remote server that I connect to over VPN in order to deploy updates.
I installed the Rewrite Module for IIS 7 and made a rule to rewrite http to https for all requests.
Suddenly I am getting this error when I attempt to acquire an authorization token (OAuth):
{
"error":"server_error",
"error_description":"Exception has been thrown by the target of an invocation."
}
And this message for any api endpoint:
I cannot for the life of me figure out what's going on. How can I get a more useful error message from asp.net or iis? I cannot do remote debugging and the server does not have visual studio installed.
I have undone all the modifications I made and its still broken.
This is usually a sign that IIS is having problems even starting the application. I'd remove everything from the web.config file and add each line in one by one until you get back to this error message. If it is an application error (i.e., something in your code) you would get a 500. Since you aren't getting a 500, it is a lower level than your application and the next lower level is IIS parsing your web.config file before serving requests.

Exe Hosted in IIS Calling Generates Http 405 Method not alllowed Error

I want to use Testtrack SDK API and for that needs to host Test Track SDK server on my server Machine, When I had installed Test Track on my server machine and tried to call it through code it gives me Error Http 405 method not allowed.
Is there any specific things which needs to be done in IIS to run exe ?
The 405 error is a security issue with the IIS web server. You can find step by step instructions for configuring CGIs with IIS in the TestTrack user documentation.
http://help.seapine.com/testtrack/2015.0.1/ttinstall/Default.htm#cshid=WebServerConfigIIS7_8

Accessing IIS's request handling pipeline to inject a request and get the html response

Is it at all possible to inject a request into IIS for a page, have IIS and ASP.Net handle it as normal, but get the response as html handed back to me programmatically?
Yes, I know that I could connect to port 80 using WebRequest and WebResponse, but that becomes difficult if you are accessing the IIS server from the same physical machine (loopback security controls et al).
Basically, I want to inject the request (eg for http://example.org/MyPage.aspx) between the points at which IIS would normally talk to the browser, and the point at which it would route it to the correct ASP.Net application, and get a response back from IIS between the points at which ASP.Net/IIS applies the httpfilters and hands the html back to the browser.
I'm predominantly working with IIS7 so if there is a solution that works just for IIS7 then thats not an issue.
You could implement a custom HttpModule, which would give you access to the IIS pipeline, including the final response. However, you would still need to initiate a request to IIS to actually kick off processing. Not sure if this would work for you.
From the MSDN documentation:
An HTTP module is an assembly that is
called on every request that is made
to your application. HTTP modules are
called as part of the request pipeline
and have access to life-cycle events
throughout the request. HTTP modules
therefore let you examine incoming
requests and take action based on the
request. They also let you examine the
outgoing response and modify it.
Gave you looked into the WebCkiebt class? You can make the request and get the response HTML.
http://msdn.microsoft.com/en-us/library/system.net.webclient.downloadstring(v=VS.100).aspx

How to update Http Request and send it to another web server

Following is our environment setup:
IIS 7 receives Http (.jsp) request from client (browser).
It blindly redirects it to JBoss using ISAPI_Redirect.dll.
Now we are trying to modify this setup in such a way that before IIS7/ISAPI_redirect sends it to JBoss, we need to modify posted form data using Http module. This http module is normal .net http module.
We are able to intercept the request # BeginRequest event of http module and when we send it to JBoss, it gives us "Read client failed (400)" error.
Any idea how to achieve this task or fix the problem at hand?
We were not able to fix our problem in its original form. What we did is we removed ISAPI_REDIRECT/JBoss from our original pipeline.
We now take the request directly to our http module by setting up another virtual directory where ISAPI_Redirect is not configured, we do our modification (earlier we intended to do this after JBoss has received the request) and then send it to another virtual directory (URL) where ISAPI_REDIRECT is configured. Now ISAPI_Redirect captures the request, maps it to JBoss format and sends it to JBoss.
Basically we switched the place of our customer processing and things seem to falling in place.

Resources