Sorry I don't mean the endpoint, I mean the WSDL location (URL), is what I
should pass to the Service constructor.

On 15 March 2013 10:48, Geeb Otron <[email protected]> wrote:

> Ok Thanks chaps.
> So what we are saying is that provided the public interfaces to both test
> and production services are the same, no code should need to be regenerated.
> I need only pass the endpoint URL to the constructor of the service to
> select which one is contacted by requests.
>
> I suppose I could store this URL in the Tomcat "context.xml" file which
> is, I believe, accessible to all web-apps hosted by that instance of
> TomCat? (At least this is where I store the Oracle connection pooling
> parameters.)
>  --
> Geeb
>
>
> On 14 March 2013 18:26, Daniel Kulp <[email protected]> wrote:
>
>>
>> As long as the WSDL's are equivalent, there should be no need to
>> regenerate everything for production vs. test.   The generated service
>> object has a constructor that takes the URL of the WSDL as a parameter.  If
>> you can get the servers URL passed into your application somehow
>> (properties file, context param, jndi, etc…), then just use that in the
>> constructor and you should be all set.
>>
>> Alternatively, as Glen mentioned, use the "local" WSDL and just override
>> the endpoint address with the request property.   Thus, the WSDL is local
>> (and thus faster to parse and such), but it would still use the servers
>> address for the actual soap request.
>>
>> Dan
>>
>>
>> On Mar 14, 2013, at 12:22 PM, Geeb Otron <[email protected]> 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.
>> >
>> > 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.
>> >
>> > 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.
>>
>> --
>> Daniel Kulp
>> [email protected] - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>
>
> --
> --
> Geeb
>
> If you ain't keen to show me the source, I ain't keen to execute the
> program.
>



-- 
-- 
Geeb

If you ain't keen to show me the source, I ain't keen to execute the
program.

Reply via email to