I have an existing servlet and want to write some instructions to my log file on how to construct the URL needed to access my service . The basic logging service in J2EE is just fine for my purposes. The items I need are:
the canonical host name (got it)
the port number(s) for http connectors found in the server.xml file
the intermediate path to my servlet (servlet installation folder),
e.g. http://host:port/intermediate path/additional path
Using these three pieces of information I should be able to leave a breadcrumb of sorts in the log that tells administrators exactly how to configure my client-side app to access to this particular servlet instance.
Getting this information from within my implementation of HttpServlet.service() seems simple but I want to display the data during startup. Any thought on how to get it from within my implementation of HttpServlet.init()?
Related
I have an BizTalk+ESB itinerary with a Itinerary Service to route the data to a web service, using a static resolver.
When I make the request I get this error:
"The document type "http://schemas.xmlsoap.org/soap/envelope/Envelope" does not match any of the given schemas."
I added Envelope.xsd to my itinerary and set the Document schema in the XmlDisassembler
and set the Envelope schema also
I have the itinerary call to the service set up as:
The service is running, and I restart the hosts every time I update the pipeline.
I'm using the schema from http://schemas.xmlsoap.org/soap/envelope/Envelope
I've been checking online and it looks as though I need to modify the schema to include the structure of the incoming message. Is that correct? I assumed that ESB would create the correct message envelope. It looks as though this is not the case.
Anyone have any advice on how I should proceed with this?
I am using axon distributed command bus autoconfiguration using spring cloud and eureka
I observed all the required beans are getting created./member-capabilities is also exchanging the command information with other services and it is I can see this mapping exists in request mappings as well. Now when the command is being sent from another service by internally making a post-call to /spring-command-bus-connector/command endpoint
I am getting 404.
I checked that SpringHttpCommandBusConnector's bean is loaded in application context
I tried adding a component scan as well
Also tried registering this mapping manually with dispatcher servlet still no luck
In servlets for mapping I use #WebServlet("/path")
It means, that I can write in form's action "/path" and button click would be handled by my servlet.
In spring mvc I map controller's method as
#RequestMapping("/path")
It means, that I must write in form's action "/webAppName/path" and button click would be handled by my method. But if name of my war file will be change, I must been change mapping on html/jsp. I think it very bad.
Can You help me?
Firstly, you are absolutely wrong. Secondly, what you have mentioned as war file name, is actually context path which even remotely has no relationship with the war name.
Context path is used by the server to refer the webapp running on it. It can be possible that there are multiple applications deployed on your server so, for server to figure out which request is related to which web application context path is required.
The context path of the web application, which is matched against the beginning of each request URI to select the appropriate web application for processing. All of the context paths within a particular Host must be unique. If you specify a context path of an empty string (""), you are defining the default web application for this Host, which will process all requests not assigned to other Contexts.
The value of this field must not be set except when statically defining a Context in server.xml, as it will be inferred from the filenames used for either the .xml context file or the docBase.
And moreover, it has nothing to do with the architecture of the application weather it be Spring MVC or Java Dyanamic Web Application the same thing applies.
I want to log the assembly version information into a log file each time my WCF web service is called. I know that in an application the My object has an Application object which has the Info structure, that contains the Version string that I can use. How can I get the version information for the WCF service to a log?
You will need to create either a separate service method GetServiceVersionInfo() that you can call when needed, or you could include the service's version info in some headers that travel along with the message.
If you want to add header to each and every message, the best way to go is create an extension called a MessageInspector. This is a small chunk of code that intercepts every message (in your case: every message going out of the server) and adds some header (or manipulates the actual message).
Read up on Message inspectors in this blog post showing how to write a message inspector, or read the MSDN docs on the topic to get started.
I'm working on a web service that uses ASP.NET security model (i.e. with AspNetCompatibilityRequirements set to allowed). Like many others, I got an error saying the Anonymous access is required because the mexHttpBinding requires it and the only way to get around it is to remove the mex endpoint from each service as described here:
WCF - Windows authentication - Security settings require Anonymous
I thought by removing mex endpoint I will no longer able to generate WSDL or add a reference to the service from Visual Studio but to my surprise everything still works. I quickly googled the "mex binding" but most web sites just say it's for "Metadata Exchange" without going into too much detail on what it actually does.
Can anyone tell me what's the side effect of removing the mex binding?
If your WCF service does not expose service metadata, you cannot add a service reference to it, neither from within Visual Studio (Add Service Reference), nor will another client be able to interrogate your service for its methods and the data it needs.
Removing Metadata Exchange (mex) basically renders the service "invisible", almost - a potential caller must find out some other way (e.g. by being supplied with a WSDL file, or by getting a class library assembly with a client he can use) about what the service can do, and how.
This might be okay for high risk environment, but most of the time, being able to interrogate the service and have it describe itself via metadata is something you want to have enabled. That's really one of the main advantages of a SOAP based service - by virtue of metadata, it can describe itself, its operations, all the data structures needed. That feature is used to make it really easy to call that service - you just point to the mex endpoint, and you can find out all you need to know about that service.
Without the metadata exchange, you won't be able to use svcutil.exe to automatically generate the proxy classes.