Re: [Mifos-developer] Some thoughts about further development of the hudsonBuildQuartz
Adam Monsen
So, it sounds like the breakdown is something like this:
1. stick w/tasks.xml
* pro: can configure batch jobs right from the UI
* con: custom code needed to support dependencies
2. use spring XML files to configure scheduler context
* pro: less custom code
* pro: more flexible
* con: can't configure batch jobs right from the UI
I like second option. Having to restart and having to modify XML files
to configure batch jobs isn't any worse than what we currently do
(unless the new XML config format is hard to understand). But we're
still presumably improving Mifos since we're moving away from custom
code to off-the-shelf (tested/performant/etc.) FLOSS.
If we went with the second option, are we making it very hard to build
something that allows batch job configuration via the user interface? I
just want to make sure we're not painting ourselves into a corner.
Configuration from the UI is a really good thing, IMHO.
Jeff, Kay and I took a peek at batchjobs.ftl... looks really cool!
On Tue, 2010-08-24 at 18:12 +0200, Jakub Sławiński wrote:
> Hi Adam,
>
> as we are getting more and more familiar with Quartz/Spring Batch
> internals, our vision of Quartz integration with Mifos evolves. Our
> initial idea was to keep our own tasks.xml format, but extend it to
> support new features provided by Quartz. However, this solution would
> still need some custom code to support dependencies between job
> executions. From the other hand, our own tasks.xml format would allow us
> to modify it directly from UI.
>
> Our current idea is to completely resign from our own tasks.xml format
> and use spring xml files to configure scheduler context. This would be
> extremely flexible, but our UI would not be able to modify it (but
> instead of this we can provide the ability to upload new spring xml file
> to configure our scheduler). Moreover, we wouldn't need any custom code
> to support task dependencies, conditional executions, etc. because such
> features are already provided by Spring Batch and can be configured by
> spring xml files.
>
> What do you think about second option? If you want to talk about this,
> let me know when you are available, so we can use Skype to discuss
> functional details.
>
>
> Yours sincerely,
> Jakub.
Adam Feuer
<amo...@grameenfoundation.org> wrote:
> 2. use spring XML files to configure scheduler context
> * pro: less custom code
> * pro: more flexible
> * con: can't configure batch jobs right from the UI
Adam, Jakub,
Why can't the UI modify the spring scheduler context? Does modifying
it require a container (tomcat) restart? Or is it a matter of parsing
the format? Would we be able to modify the file if we later wrote some
more software to do that?
cheers
adam
--
Adam Feuer <adamf at pobox dot com>
------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
Emily Tucker
Fwiw, given our focus right now on cloud deployments-- this seems like a much lower priority (at least from a biz perspective!) than the other goals.
Emily
Jakub Sławiński
> Why can't the UI modify the spring scheduler context? Does modifying
> it require a container (tomcat) restart? Or is it a matter of parsing
> the format? Would we be able to modify the file if we later wrote some
> more software to do that?
>
>
It is a matter of parsing the format. Even authors of the Spring Batch
Admin (http://static.springsource.org/spring-batch-admin) do not allow
to modify xmls directly from the UI, but allow to upload new xmls to
reconfigure/add new jobs. I think that this approach should be also
sufficient for us (read-only Batch Jobs management page with the
possibility to run jobs on demand, temporarily suspend
scheduler/particular jobs and upload new xml files).
Jakub.
Adam Feuer
> It is a matter of parsing the format. Even authors of the Spring Batch
> Admin (http://static.springsource.org/spring-batch-admin) do not allow
> to modify xmls directly from the UI, but allow to upload new xmls to
> reconfigure/add new jobs.
Jakub,
Ok, cool.
> I think that this approach should be also
> sufficient for us (read-only Batch Jobs management page with the
> possibility to run jobs on demand, temporarily suspend
> scheduler/particular jobs and upload new xml files).
Yes, this sounds fine! Thank you for the info.
-adam
--
Adam Feuer <adamf at pobox dot com>
------------------------------------------------------------------------------
Jeff Brewster
>> sufficient for us (read-only Batch Jobs management page with the
>> possibility to run jobs on demand, temporarily suspend
>> scheduler/particular jobs and upload new xml files).
Jakub,
+1 on this approach. Testing the extra flexibility of altering the tasks from the UI would be costly.
Thanks,
Jeff
Emily Tucker
Just to be clear (someone on the team misread the intent of my email)-- moving our batch jobs to Quartz is a super high priority from the business team [we've been feeling the pain of a homegrown batch job system for a long time now].
I was just making a comment that the UI wasn't as high a priority-- esp if it meant not being able to leverage off-the-shelf quartz functionality.
Anyways, think we're all in alignment-- and it's exciting to know this project is close to completion!
Emily
> > * con: can't configure batch jobs right from the UI
>
> Fwiw, given our focus right now on cloud deployments-- this seems like
> a much lower priority (at least from a biz perspective!) than the other
> goals.
>
> Emily
Adam Feuer
<ETu...@grameenfoundation.org> wrote:
> Anyways, think we're all in alignment-- and it's exciting to know this project is close to completion!
Yes - we will use Quartz and Spring DM's config file format, with no
UI for that now.
I'm also excited about this! It's a big step forward! Thank you Jakub and team!
-adam
--
Adam Feuer <adamf at pobox dot com>
------------------------------------------------------------------------------