http://ofbiz.116.s1.nabble.com/Users-Debugging-Scheduled-Jobs-Tip-tp137457p137466.html
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
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> ---
>