I have found this URL, which discusses getting Tomcat context parameters,
(from context.xml etc.) into a Spring web app.
Refer to section(3)

http://blog.carbonfive.com/2008/04/25/configuring-applications-with-spring/

Cheers!
-- 
Geeb

On 15 March 2013 12:19, Geeb Otron <[email protected]> wrote:

> 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.
>



-- 
-- 
Geeb

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

Reply via email to