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.
(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.
>
>
>
>> Currently I use a property inside the Maven pom.xml to replace the local
>> path the WSDL file as I generate code for a specific environment. (I keep
>> local copies of the WSDL files for all the instances of the web-service)
>>
>
>
>> As I say, ideally I would like to bypass having to regenerate and compile
>> the code completely if possible, as it seems a faulty approach to tamper
>> with an artifact that has been signed-off in testing, before it reaches
>> production!
>>
>> Thanks for any advice!
>>
>
>
--
Geeb
If you ain't keen to show me the source, I ain't keen to execute the
program.
