On 03/14/2013 01:29 PM, Geeb Otron wrote:
On 14 March 2013 16:47, Glen Mazza <[email protected]> wrote:
On 03/14/2013 12:22 PM, Geeb Otron wrote:
Hello,
My question is about auto-generation of CXF code in test and production
environments.
My web app:
1. Consumes a remote web-service
2. Connects to an oracle DB
3. Uses the Spring framework
4. Uses Maven
5. Runs on tomcat and is exported as a WAR file.
I have different environments in which I need to run my app, and
ultimately
publish into a production environment, using a production instance of
Oracle, and of the web-service.
What I want to know is the best-practice in terms of having the minimum
amount of environmental config inside my app and the maximum in the
environment in which the app runs.
For example, with the Oracle database, a connection pool (C3P0) is
configured and managed by Tomcat, so my app simply uses a named resource
to
grab a database connection object (configured as the web-app starts in the
Spring XML config files, and in the web.xml file)
So irrespective of where the web-app is running the Tomcat instance
provides the connection pool for the the correct database: No
configuration
is required in my app other than getting the <resource-ref> section of the
web.xml file correct in the first place, as all instances of Tomcat uses
the same name for their DB connection resource.
Is there a similar approach for configuring the reference to the service
endpoint on the instance of Tomcat that hosts my web-app?
I use the Maven cxf-codegen-plugin and currently have to regenerate and
rebuild the underlying CXF source code as I move from consuming the test
version of the web-service, to the production one.
Make sure you use a WSDL location similar to
<wsdlLocation>classpath:**DoubleIt.wsdl</wsdlLocation>
Yes, I substitute the path, but it's relative to the classpath:
<wsdlLocation>classpath:wsdl/${ws_status}/Cmis.wsdl</wsdlLocation>
Here the ${ws_status} is the property I pass in, which amounts to either
"test" or "live", obviously with equivalently named directories.
OK, you could also pass in classpath:${wsdl.file.name} for a different
WSDL name (say prodcmis.wsdl and testcmis.wsdl) that will have a
different URL within it. That might get rid of your need for separate
folders.
(i.e., use classpath: instead of a hardcoded string), so the generated
artifacts will not be pointing to a specific folder location on your
machine but the supplied classpath instead.
Ideally I would like to generate the CXF code once (as the service
endpoints use pretty much the same public interfaces), but for the app to
pick up the specific URL of the service from the Tomcat environment and it
not have to be hard-coded into the web-app.
CXF largely already does that, it follows this algorithm when it replaces
the URL in the WSDL you provide it:
http://www.jroller.com/gmazza/**entry/web_service_tutorial#**notes<http://www.jroller.com/gmazza/entry/web_service_tutorial#notes>(note
#2)
(I'm assuming you're talking about hosting a web service provider on
Tomcat and not just a client, in the latter case it will rely on the
hardcode URL in the WSDL.)
The service is not using CXF or running on Tomcat - it happens to run
Windows WCF (I didn't originally write this service. I simply download and
use its published WSDL)
In this scenario, I'm only developing the client web-apps.
Well, you can always use BindingProvider.ENDPOINT_ADDRESS_PROPERTY (
http://www.jroller.com/gmazza/entry/soap_client_tutorial) to change the
endpoint URL dynamically from the code -- I'm not sure how/whether a
hosted WAR can read and apply values from the servlet container (here,
Tomcat) hosting it. What you're asking is maybe more a Tomcat user's
mailing list question than a CXF one. (Basically, you have a Java source
file and you want to alter values within it based on the Tomcat it is
deployed on.) Of course, you can use a Spring context file that you
store with the WAR and use DI to pass in the desired endpoint URL to
access. But I don't enough of what you're doing to be able to comment
in more detail, hopefully others can provide better tips.
Glen
