http://ofbiz.116.s1.nabble.com/Users-Debugging-Scheduled-Jobs-Tip-tp137457p137467.html
David is correct-- there shouldn't be "meta config" files for environments.
mentioned), or by subdirectory (as Joe mentioned). I think the file
this approach (by file extension) and see how it goes. If it works, I'll
David E. Jones wrote:
>
> Hmmmm... I always considered the serviceengine.xml file to _be_ a
> "local config" file....
>
> -David
>
>
> On Feb 16, 2006, at 10:47 AM, Florin T.PATRASCU (work) wrote:
>
>> Guys, I don't know if this sounds alien, but David, how difficult
>> will be to improve the UtilXml.getXmlRootElement(...) (or a better
>> place?) to "decorate" the loaded xml config files with parameters
>> defined in a properties file or coming from the System properties,
>> classpath, JVM params or etc...??
>>
>> In our case this will look like this:
>>
>> local property file defining:
>> send-to-pool=devServerA
>>
>> And then in the serviceengine.xml we could simply have:
>> ...
>> <thread-pool send-to-pool="${send-to-pool}"
>> purge-job-days="4"
>> failed-retry-min="3"
>>
>> ...
>>
>> And then the developer only has to tweak his local config file.
>>
>> I don't know how realistic my proposal is, but I was just thinking
>> about, anyway please consider it my 2 CAD cents intervention to this
>> thread ;)
>>
>> -florin
>>
>>
>> David E. Jones wrote:
>>>
>>> Patches are generally easier to maintain...
>>>
>>> They can also be applied using ant if you create sets of build targets.
>>>
>>> -David
>>>
>>>
>>> On Feb 16, 2006, at 10:20 AM, Lon F. Binder wrote:
>>>
>>>> David (and everyone),
>>>>
>>>> That's a good idea. Alternatively, this is
>>>> bigger-picture-approach, perhaps we should alter the build file to
>>>> include build targets by environment, that way we can standardize
>>>> ofbiz projects on a file extension that can be picked up and
>>>> removed per target.
>>>>
>>>> Using Florin's great tip as an example, I might have:
>>>> serviceengine.xml@Lon
>>>> serviceengine.xml@B1
>>>> serviceengine.xml@production
>>>> Where the String following the '@' is free form.
>>>>
>>>> Then we could add a build target that accepts a parameter. When
>>>> files end in "@${param}" that extension is removed locally.
>>>>
>>>> So if I did a "build B1" upon build it would choose
>>>> "servicengine.xml@B1" as listed above, and create a copy in the
>>>> same folder called "serviceengine.xml".
>>>>
>>>> The goal being to use the same freeform extension for whatever
>>>> means across the entire fileset for environment-sensitive files.
>>>> Having a freeform extension would allow for unlimited environments
>>>> (which is particularly helpful on projects with many devs). And
>>>> doesn't require any special repository work to maintain.
>>>>
>>>> Thoughts?
>>>>
>>>> - Lon
>>>>
>>>> -----Original Message-----
>>>> From:
[hidden email]
>>>> [mailto:
[hidden email]]
>>>> On Behalf Of David E. Jones
>>>> Sent: Thursday, February 16, 2006 11:42 AM
>>>> To: OFBiz Users / Usage Discussion
>>>> Subject: Re: [OFBiz] Users - Debugging Scheduled Jobs Tip
>>>>
>>>>
>>>> Yes, this is the way to go...
>>>>
>>>> We usually recommend keeping a local repository with a base set of
>>>> code and configuration files for a "development" mode, and then
>>>> keeping a directory with patches (in the repository) for the
>>>> various servers. When OFBiz is deployed on each server (test,
>>>> staging, production, perhaps multiple of
>>>> each) you just check out the rev you want to deploy, apply the
>>>> patch for that server, and build and run.
>>>> This makes things more easy to reproduce and allows for
>>>> configuration variations between servers.
>>>>
>>>> -David
>>>>
>>>>
>>>> On Feb 16, 2006, at 8:58 AM, Florin T.PATRASCU (work) wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> The way to avoid this is to use the service engine *pool* feature
>>>>> that allows each service engine instance to specify which pool it
>>>>> "publishes"
>>>>> to by default, and which pool(s) it "subscribes" to.
>>>>>
>>>>> excerpt from serviceengine.xml installed on a Test server:
>>>>>
>>>>> <!-- Thread pool configuration (max/min threads, uses to live
>>>>> and time to live) -->
>>>>> <thread-pool send-to-pool="hobbit1"
>>>>> purge-job-days="4"
>>>>> ....
>>>>> poll-db-millis="20000">
>>>>> <run-from-pool name="hobbit1"/>
>>>>> </thread-pool>
>>>>>
>>>>>
>>>>> while the same serviceengine config file but on a Production
>>>>> machine will look different a bit:
>>>>>
>>>>> <thread-pool send-to-pool="everest01"
>>>>> ....
>>>>> poll-db-millis="20000">
>>>>> <run-from-pool name="everest01"/>
>>>>> </thread-pool>
>>>>>
>>>>> Just make sure they have different names for your development
>>>>> servers and your production servers and this problem should go
>>>>> away. We encountered this issue in the past. So you can still
>>>>> share your db and get advantages from that;)
>>>>>
>>>>> I hope it helps.
>>>>>
>>>>> -florin
>>>>>
>>>>> PS
>>>>> Sorry for my English if it is confusing :( but I believe is better
>>>>> than the one Andrew Dupa is "using" ;)
>>>>>
>>>>> Lon F. Binder wrote:
>>>>>> All -
>>>>>>
>>>>>> After spending a few hours working through an issue, I'd like to
>>>>>> provide an interesting (albeit obvious in hindsight) tip.
>>>>>>
>>>>>> We had two different OFBiz installations sharing the same database.
>>>>>> One was a dev environment, the other was a QA environment (for
>>>>>> the same target application). This led to different versions of
>>>>>> the same codebase across the two environments. All in all, this
>>>>>> was a fine approach for sharing the general data (store, catalog,
>>>>>> parties, etc.).
>>>>>>
>>>>>> However, a consequence was overlapping job queue workers.
>>>>>> Depending on the timing jobs would be worked on by the two
>>>>>> applications running. And because the code base was slightly
>>>>>> different (due to ongoing development), sometimes the jobs would
>>>>>> work and sometimes they wouldn't.
>>>>>>
>>>>>> TIP: Don't let multiple OFBiz application environments (dev, qa,
>>>>>> etc.)
>>>>>> share a single OFBiz database, at least while you're
>>>>>> testing/developing scheduled jobs.
>>>>>>
>>>>>> - Lon
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> ----
>>>>>>
>>>>>> ---
>