Wise SoapClient limitations?

[boy18nj]

We are using ESB version- 4.9_SOA_5.1

The only reason i don't want to use wise soapclient because of variable subsitution problem in wise-core.properties

wise.tmpDir has differenent values in windows and unix. This becomes hardcoded in code. I would like use something like  wise.tmpDir=${wise.location.dir} - will this work or any other custom solutions to make wise-core.properties indepdent of platform?

Windows

wise.tmpDir=D:/tmp
wise.forceImportObject=true

wise.keepGeneratedSources=true

wise.wsImporter.verbose=true

wise.targetPackage=org.jboss.soa.esb.samples.quickstart.webservice_consumer_wise4.generated

Unix

wise.tmpDir=/tmp
wise.forceImportObject=true
wise.keepGeneratedSources=true
wise.wsImporter.verbose=true
wise.targetPackage=org.jboss.soa.esb.samples.quickstart.webservice_consumer_wise4.generated

[tcunning]

I guess I'm not understanding your objection here - properties files are used to separate out platform or machine specific properties from code or build scripts.         The quickstart example that you reference (webservice_consumer_wise4) does the exact thing you are talking about - it provides a way of specifying specifying these properties for different machines.   You shouldn't need to use variables for a properties file value.

If you don't want to change it by hand, you can always make wise.tmpDir's value a token and then use token replacement, depending on what OS is detected, although that seems a little excessive.

[boy18nj]

Ok I will try to explain further.

Suppose you have following file saved in SVN

wise-core.properties

Unix

wise.tmpDir=/tmp
wise.forceImportObject=true
wise.keepGeneratedSources=true
wise.wsImporter.verbose=true
wise.targetPackage=org.jboss.soa.esb.samples.quickstart.webservice_consumer_wise4.generated

-

I deploy the code from SVN in UNIX. It works Ok. I try to deploy the same code on windows- it fails miserably because wise.tmpDir=/tmp won't work on windows .

Now what do we expect the developer to fix the code. The developer will fix the code to wise.tmpDir=D:/tmp and checks in SVN. Good- works in windows. Ohh..now it doesn't works in UNIX.

I hope it clears out.

If you don't want to change it by hand, you can always make wise.tmpDir's value a token and then use token replacement, depending on what OS is detected, although that seems a little excessive.

How this can be done? Are you saying to do code replacement inside *.esb file?

The quickstart example that you reference (webservice_consumer_wise4) does the exact thing you are talking about - it provides a way of specifying specifying these properties for different machines.   You shouldn't need to use variables for a properties file value.

Inside example- webservice_consumer_wise4- readme.txt says-

To Run:

===========================

    1.  Open wise-core.properties and modify the property 'wise.tmpDir' there to suit your environment.  

We know there is always 1 respository shared across different environments Unix and Windows. There must be way to do variable substituion inside this property file or if possible to set properties dynamically thru jboss-esb.xml

[tcunning]

If you're concerned about properties files being checked in to svn, don't directly check the properties file in - name it something different (wise-core.properties-example?).      We do that in the ESB build - we force the user or developer to copy installer.properties-example to installer.properties.       Either way, you need someone to edit that file before deployment.

Your other option is token replacement :

http://ant.apache.org/manual/Tasks/replace.html

There's an example of this in the helloworld_ftp_action quickstart, where the jboss-esb.xml is "unfiltered" at start and contains tokens, but replacement happens through the build.xml targets.       In your situation, you would want to filter your properties file, based on os, which ant can detect.

http://ant.apache.org/manual/Tasks/conditions.html

You can set properties dynamically through jboss-esb.xml as well, this link describes a few ways, but I really think you are missing the boat on build vs. deployment use of properties files.

http://pontus.ullgren.com/view/Creating_reusable_JBoss_ESB_archives

[boy18nj]

Thanks