http://ofbiz.116.s1.nabble.com/Users-Debugging-Scheduled-Jobs-Tip-tp137457p137464.html
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
>>>>
>>>> ---------------------------------------------------------------------
>>>> ---
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>>
[hidden email]
>>>>
http://lists.ofbiz.org/mailman/listinfo/users>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>>
[hidden email]
>>>
http://lists.ofbiz.org/mailman/listinfo/users>>
>>
>> _______________________________________________
>> Users mailing list
>>
[hidden email]
>>
http://lists.ofbiz.org/mailman/listinfo/users>>
>>
>>
>> _______________________________________________
>> Users mailing list
>>
[hidden email]
>>
http://lists.ofbiz.org/mailman/listinfo/users>
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> Users mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/users