I have Glassfish 3.1.1 (Metro JAX-WS stack) installation with several http listeners in my domain's virtual server.
When I deploy my EAR, web application and soap services are all bound to all available http listeners whereas I want them to be held by different listeners, each having it's own performance and connection pool setup.
I believed that sun-web.xml should be responsible for that sort of binding but I haven't found any options of binding service to specific port or virtual server.
Any ideas?
One option is to use the deploy command with an accordingly set virtualservers commandline parameter... for reference see http://download.oracle.com/docs/cd/E18930_01/html/821-2433/deploy-1.html or page 262 etc. at http://download.oracle.com/docs/cd/E18930_01/pdf/821-2433.pdf
Another option:
Several config files have new names (for example glassfish-web.xml is the new name for sun-web.xml).
To bind your EAR to specific URI see esp. the web element and its sub-element like web-uri - for details and samples see
http://download.oracle.com/docs/cd/E18930_01/html/821-2417/beaqk.html#scrolltoc
http://download.oracle.com/docs/cd/E18930_01/html/821-2417/beaql.html
http://javahowto.blogspot.com/2010/10/glassfish-webxml-and-sun-webxml.html
Related
I am new in the area of SOAP Based web services. I am using TomEE server. The server is a bit customized according to my organization's need.
Few days back, when I was trying to run the web services example from TomEE website, I was able to generate the wsdl and calling the web service by a client.
Now, when I need to use the customized version of TomEE plus (by the organization), I can see that the request does reach to the server and hence there is a log entry also but my #WebMethod is not getting executed.
Does any one has any idea about any configuration which can prevent the request from reaching to the webservice method? Is there any pointer around how can I debug further to reach out to the root cause of this issue?
Without further information about what is customized it's like fishing in the dark.
I would guess that perhaps the global web.xml or the server.xml of tomee server is changed so that some URI context mappings are not forwarded or ignored. But it's only a lucky tip.
I am working on a central headless service, based on Equinox, that should support plug-ins to contribute web functionality. The head is to manage the main entry point for web requests (that is the HttpServer on port 80 and 443) and yet I would like to leave the plug-ins to use their own communication technologies.
One case I have here is vert.x so the scenario is that I initially take the connection from Jetty and then, if the url leads to the resp. plugin, pass it to the vert.x instance.
So. e.g. a call to http://example.org/vertxplugin leads to the inital http://example.org accepted by Jetty which then identifies the vertxplugin as target passing the resp. connection.
Currently I do not see how such a scenario can be realized - as I see only examples of vert.x generating the HttpServer or jetty generating the HttpServer.
Additionally is something like
// create the websocket
vertx.createSockJSServer(httpServer).bridge(config, inOK, outOK);
where the httpServer mentioned here is Jetty, possible??
Thanks for any hints.
I have the same mule webservice application with 2 different versions deployed on the same mule server. Let's call it MuleApp.1.0 and MuleApp.1.1. The flow is as simple as the example of webservice flow on mulesoft website. Their wsdl urls are different as:
http://www.myhost.com:25101/MuleApp.1.0/Service?wsdl
http://www.myhost.com:25101/MuleApp.1.1/Service?wsdl
Both of them are working as expected when the other is not deploying on the mule server. The issue happens when I having both of them deployed on the same mule server like what I used to do in WebLogic. Now I am able to access MuleApp.1.1, but when I tried to access MuleApp.1.0, I got the error as below
07-Mar-2013:14:52:57.142 VWILVM3667 [MuleApp.1.1].connector.http.mule.default.receiver.03
WARN org.mule.transport.http.HttpMessageReceiver NA
No receiver found with secondary lookup on connector: connector.http.mule.default with URI key: http://www.myhost.com:25101/MuleApp.1.0/Service
This is supposed to be a very common versionning case. What did I miss in my config?
You can't have two different applications sharing the same HTTP port in the same Mule instance.
So what probably happens is that MuleApp.1.0 doesn't deploy properly (check the logs), which is why there is no endpoint listening on /MuleApp.1.0.
Either:
Use a different port in the two apps,
Put both flows in a single app.
Create a frontal app that listens on port 25101 and both /MuleApp.1.0 and /MuleApp.1.1 paths and that dispatches requests to MuleApp.1.0 and MuleApp.1.1 on private ports (say 25102 and 25103).
I finally deployed my application on tomcat, and replaced http inbound endpoint with servlet inbound endpoint. I configure the web.xml with servlet class org.mule.transport.servlet.MuleReceiverServlet. Now I am able to deploy multiple applications on the same port.
We are building a web application where we are following SAAS model using RESTful services for internal communication between modules.
There is a scenario where we want to resolve the host name of the server for RESTful service through one of the parameter value passed in the URL of service. In our architecture, each server instance wants to provide it's service for a set of values of a particular parameter in the URL.
In a dynamic environment, such responsibility can change from server to server. How can the client resolve dynamically which IP address it should contact to get a particular request served? Is there some sort of URL service registration and resolution facility similar to DNS, which can take into consideration some metadata like parameter's value in the resolution procedure? Any links to some existing solution or ideas for implementing such thing are welcome.
You can use a reverse-proxy as front-end of your service (all worker servers). It must be capable of directing request to appropriate back-end server based on some knowledge about application-level semantics in URLs, including parameters.
Here is the list of the most commonly used reverse-proxies:
Nginx (specifically about reverse-proxying)
Squid
Apache with mod_proxy
The main thing to note is that these general purpose products may not meet your needs well, in the sense of how flexible they can be congifured. This is why I wrote a custom reverse-proxy for a similar web-service myself (the project was implemented in Delphi, and I can provide some further details on this if needed).
All of them are web services, but what's the difference?
WSDL (Web Service Description Language) is a standard notatation for describing a Web Service in xml.
DISCO is a tool for querying SOAP and similar services and extracting useful information from the WSDL provied.
EVENTs is a proposed standard which uses WSDL and extends WSDL to support publish subcribe type event driven processes.
WSDL:
WSDL is a markup language that describes the web service. In order to use this Web service, the Client application developers need to know the methods exposed by the Web service and the parameters to be passed to these methods. It is imperative that access to these methodologies is available at development time and it is just this need that WSDL addresses.
DISCO:
The Web Service Discovery Tool (DISCO) is used to discover the URLs of XML Web Services located on a Web server and saves documents related to each XML service on a local disk. The DISCO takes the URL and discovers and produce publishes discovery documents (.wsdl, .xsd, .disco and .dicomap files) as arguments. Some of the options available for use with this tool are:
/d[omain]:domain - Specifies the domain name to use when connecting to a proxy server that requires authentication
/nosave - Does not save the discovered document or results
/nologo - Suppresses the Microsoft startup banner display
/o[ut]:directoryName - Specifies the output directory in which to save the discovered documents. Current directory is the default one.
/p[assword]:password - Specifies the password to use when connecting to a proxy server
/proxy:url - Specifies the URL of the proxy server to use for HTTP requests.
DISCO is a tool, not a web service itself.
EVENT:
if you mean to WS-Eventing, see here.
UDDI- UDDI is a central directory. It will have web services listed from multiple domain and servers.
DISCO- Disco contain web services listed from one domain and server.By which particular web service can be selected.
WSDL- It describe the rules or grammar for the function that are exposed in the web services.