Announcement Announcement Module
No announcement yet.
implement personalized xml authoring over SB xml authoring Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • implement personalized xml authoring over SB xml authoring


    We would like to create our own schema-based extensions to ease development four our business programmers.

    This need come from the fact that we created a lot of personalized Spring Batch helpers and configuration practices for the needs of our jobs. For example all of our jobs always need to reference a precise listener, all of them must contain the same step as first step, all steps must have the same parent... Lot of things that make each job declaration in our programs very redundant.

    So we would like to do Xml authoring just like it was done for spring Batch to ease declarations of Spring Batch jobs, steps, flows, etc...

    Example: we would like to convert automatically something that looks like this configuration
    <us:xyz-job reader="myreader" processor="myprocessor" writer="mywriter"/>
    into this Spring Batch configuration
    <job xmlns="">
    	<step id="precedingstep" next="mainstep">
    	<step id="mainstep">
    			<chunk reader="myreader" processor="myprocessor" writer="mywriter" commit-interval="2"/>
    	<validator ref="..."/>
    The problem is that, as far as I know (although I must admit I don't know a lot about Spring's XML authoring) there is no direct way to reuse existing schema-based extensions to create our own schema-based extensions. What I mean is that, even if we have a clear idea of the transition from our Xml elements to Spring Batch Xml elements, those are not reusable because Spring's Xml authoring functionality is conceived in such a way that we have to create instances of BeanDescription, there is not directly a possibility to reuse existing extensions.

    That's a problem for us, as, I've seen by reading Spring Batch code, the many parsers used to generate jobs definitions are quite complicated.

    Any suggestions that could ease our task?

  • #2
    If your use case is really that simple then a namespace probably doesn't add much value - you can just use a parent step (or a factory bean that hides the details if you want to make it a one liner).

    I wouldn't rely on the internals of the batch namespace parsers being stable.