All WSDLs I have seen so far, use localhost to describe the services address. e.g.:
<wsdl:service name="SQLService">
<wsdl:port name="SQLServiceSoap" binding="tns:SQLServiceSoap">
<soap:address location="http://localhost:8080/rservice/services/SQLServiceSoap" />
</wsdl:port>
</wsdl:service>
But when the client of such service is run, it somehow knows where the real URL of that service, even if run on a remote machine!
How does CXF perform this "magic"?
IOW, how does the client JAR on a test machine which is not the machine on which the service runs, know where that server is and its address?
I grep-ed the source code and strings-ed the client's jar file and found no trace whatsoever to the server's URL.
So how does that work?
UPDATE: In my super natural detective efforts, I just found a file named config.xml in the directory where the client's JAR file is located. That config.xml contains the actual server's URL. So it appears that this is how this is done in the particular case of the project I inherited.
Now the question(s) is:
Is this the standard way of doing this?
Is there a standard (or recommended way) at all in CXF?
Or is it pretty much left to the developer to decide?
In many cases, the web service will have a production URL and a test/QA/UAT URL. The developer will develop against the test URL, and then once it's ready for production he will switch the URL to point to production.
It is up to the developer to decide how this is accomplished and there is no standard way of handling it.
Related
I have a simple CRUD application with backend code in dropwizard. The entire app just comprises of simple resource classes and crud operations except one case where some business logic is involved.
I am trying to extract this into a service instead of putting it in the resource class itself. But for that my service would need an ondemand jdbi connection to access data and do its thing.
All my connect strings and config values are in YML file. Since this app would be running on different servers with different yml files, I dont want to hardcode the yml file name in order to read it again, to get the connect strings and do it that way.
How do I achieve this?
Can you detect what environment you are on?
If so, can you do something like ${environment}.yml?
There is Configuration project on apache which might help.
Otherwise, is it a case of in dev you want to run
java -jar app.jar server dev.yml
and in prod you want to run java -jar app.jar server prod.yml? I imagine you have separate daemons in each environment. So, those environment's will pick up the right configuration, if you've configured them that way.
Otherwise, if the property names are the same, but their values differ, and you pick up the right yml in the right environment, things should work.
If I haven't addressed your question, can you please elaborate your problem a little more?
I have task to deploy my grails application on remote office. It was far from my current location and it would be waste of time to travelling there to send update.
But I got another problem, we have slow, unreliable and limited quota for internet connection (3rd world country problem). 1 war file is about 55-60 MB.
I also don't want to send my code to them and let them compile and run it.
Could we use SVN/GIT just to send the update of compiled class to them ?
if yes, how to do that ?
If your application is having <Context reloadable="false" /> then
You can simply replace the class files(which are changed) in the location
apache-tomcat/webapps/applicationName/WEB-INF/classes
You could use something like rsync (or robocopy if you're on Windows) to copy to your remote office. That way, for each update, only the changed parts need to be transferred over the network and you should have less data sent. You could rsync the WAR file itself, or a directory which is the WAR file exploded (uncompressed). One might be more efficient with network traffic than the other, but you'd have to test that yourself if you wanted to go that far.
Also, don't forget that Groovy is compiled down to Java class files. So even if they don't have your source code they can decompile the class files and get source out of it (even though it won't be as pretty). This is worth remembering if you have any "secrets" (database password, etc.) in your source code.
I have a windows service which downloads some files from SFTP and uploads it to database and generates PDf's from that data. So now when i should give the executable files to my client i think he need to change the app config file like sftp details and the pdf paths. So i am just thinking about a program like a windows forms or a console which reads the input and save those in app config file. Is it possible like and by the way i have created a setup project for the windows service where he gets 2 files .msi file and setup file. Is it possible to achieve the above problem in this case ?
If I understand correctly, you're wanting some kind of UI application that allows the user to configure the operation of the Windows service. This is certainly possible as I've been doing it for several years now. However, you don't want to do this via the app.config file. The app.config file is read by the Windows service when it starts up, so any changes made to it would go unnoticed until the service restarts. A better course of action would be to communicate the changes to the service via the Windows Communication Foundation (or some other ICP mechanism, e.g., pipes, sockets, shared memory, etc.). I've managed to use this successfully, although to be honest, I'm using ordinary sockets now. In any case, the service would basically "listen" for incoming configuration messages, "read" those messages, and then "configure" itself accordingly, perhaps even saving the changes in its app.config file so the changes are preserved for when the service restarts later.
HTH
We've written a webservice dll with Delphi XE2 and it is running in our IIS7 server, accessible with the url http://server/webservice.dll/soap
To be able to debug the service, I've created a webservice.exe project, which can be run in the WebAppDebugger of Delphi. The problem now arrises that the webservice running in the debugger is accessible with the url http://localhost/webservice.webservice/soap
Our client application has the last part of the url "webservice.dll/soap" hardcoded (security reasons) so i cannot change that when testing with our client application, the server-address part "http://server/" is configurable in the client.
So, my question: How can i register the debug service in my webappdebugger to use an url like my production dll?
I've found the solution myself ;-)
In the initialization of the debugform there was the following line:
TWebAppSockObjectFactory.Create('Webservice');
changing this to:
TWebAppSockObjectFactory.Create('dll');
made the overall address change to http://localhost/Webservice.dll/
This did leave a small problem that the debugger project had to be renamed to Webservice.exe in stead of WebserverDebug.exe as it was called, but moving it to subfolder made this rename possible.
I start my azure application, I browse to the svc file http://127.0.0.1:82/transaction.svc,
and I get the usual:
You have created a service.
To test this service, you will need to
create a client and use it to call the
service. You can do this using the
svcutil.exe tool from the command line
with the following syntax:
svcutil.exe
http://rzv-pc:5100/Transaction.svc?wsdl
If i go to http://rzv-pc:5100/Transaction.svc?wsdl the age is blank.
If I go to http://127.0.0.1:82/transaction.svc?wsdl, I get the wsdl but there are still references like
<xsd:import schemaLocation="http://rzv-pc:5100/Transaction.svc?xsd=xsd1"
I can't use svcutil on any of this links. What is the problem? I use Azure SDK 1.1.
See http://code.msdn.com/wcfazure (particularly the "known issues" page). The issue stems from the fact that there are two ports involved. One is the external port (that the load balancer listens on), which is port 82 in your case. The other is the internal port, that your code listens to on its VM in the cloud, which is port 5100 in your case.
Note that in SDK 1.3, you can specify the localPort attribute on your endpoints, which lets you choose what that internal port is. You can make it the same as the external port and thus avoid all strangeness.