You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@batchee.apache.org by Scott Kurz <sk...@gmail.com> on 2014/12/18 19:26:02 UTC

Batch 1.1 spec kickoff

Just wanted to draw your attention to the kickoff of the next round of spec
work, as I mentioned on our spec mailing list.

https://java.net/projects/jbatch/lists/public/archive/2014-12/message/9

(Apologies if you're already following that list and this is a
duplicate/spam...)

Would be interested to hear your thoughts and ideas... as well as receive
your contributions and assistance !

(That said, I clearly need to do some work on a contributor guide/wiki,
which is one of my first intentions, esp. TCK contribution guidance).

Re: Batch 1.1 spec kickoff

Posted by Romain Manni-Bucau <rm...@gmail.com>.
done, commented inline with the links

Thanks for the ping BTW


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-09-04 20:35 GMT+02:00 Scott Kurz <sk...@gmail.com>:

> Hi Romain,
>
> As I'm looking at the 1.1 spec candidate list, I remembered this e-mail.
>
> The majority of your ideas have not already been raised, so just wanted to
> encourage you to do so by opening a bug
> https://java.net/bugzilla/enter_bug.cgi
>
> I'll save you some time by noting some that were already opened:
>
>
> On Thu, Dec 18, 2014 at 1:37 PM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> >
> > - Java API to define batches, I expect something like what was done
> > with Jsf to build flows, in 2 words a "registration" event where we
> > can use a batch builder to add batches - should of course works with
> > CDI. Idea is basically 0 xml.
> >
>
> https://java.net/bugzilla/show_bug.cgi?id=4991
>
> commented

>
> - A way to wait an execution (caricaturally an execution would be
> > linked to a countdownlatch we can await()).
> >
>
> https://java.net/bugzilla/show_bug.cgi?id=7284
> (though not specifically with the countdownlatch)
>

commented in term of API and not that technically


>
> - why not a JAXRS front for JobOperator since JAXRS is in web profile now
> >
>
> Sounds new.
>

https://java.net/bugzilla/show_bug.cgi?id=7287


>
>
> > - more CDI integration: @Inject JobOperator op; (just to align on
> > programming model but clearly not a blocker) and scopes: @StepScoped,
> > @JobScoped, @ChunkScoped at least without thinking more. Maybe also
> > CDi events for event corresponding to current listeners
> >
>
> I don't see one open for the scopes.  I'd probably open one myself.
> @Inject JobOperator is:
> https://java.net/bugzilla/show_bug.cgi?id=5075
>
>
>
https://java.net/bugzilla/show_bug.cgi?id=7288


>
> > - wonder if we could get some conversion between components. If a
> > reader returns a Foo then a processor reads a bar could the conversion
> > Foo->Bar be defined outside JBatch components (be done automatically
> > said otherwise)
> >
>
> Not really sure what you mean
>
>
https://java.net/bugzilla/show_bug.cgi?id=7289


> - you can look batchee-extras, we provide few utilities, some could be
> > surely added to the spec like BufferedItemReader
> >
>
> Seems new.
>
>
Let forget it for now, point was to provide/require some default component
implementation like reading a file, but maybe you are right and it is too
early.


>
> > - async processing (writer would then wait on Futures but at least
> > processing could be done in parallel)
> >
>
> Seems new.
>
>
https://java.net/bugzilla/show_bug.cgi?id=7290


>
> > - integration with bean validation (like JAXRS parameters surely)
> >
>
> I was thinking of bean validation on injection properties though I don't
> think we opened an issue yet (I will at some point)...not sure what you
> mean in saying "like JAXRS parameters"
>
>
https://java.net/bugzilla/show_bug.cgi?id=7291


>
> > - chaining: I want to call a chain of 5 processor or I read from 2
> > writers etc..., how do I "aggregate" my components out of the box?
> >
> >
> New.
>
>
https://java.net/bugzilla/show_bug.cgi?id=7292


> ---
>
> Having said that, there are some I'm already leaning against to various
> degrees.     E.g. the XML-less job was specifically rejected by the
> original EG in 1.0.    The utilities would have to be very "final" to be
> worth standardizing..... haven't looked at the extras much, but not sure I
> think BufferedItemReader is doing enough to bother.
>
> So I don't want to seem like I'm encouraging you to open them up so I can
> shoot them down on the public spec list.    OTOH, trying to keep the spec
> determinations on the spec list so not trying to give too strong an opinion
> here.
>
> Thanks
> Scott
>

Re: Batch 1.1 spec kickoff

Posted by Scott Kurz <sk...@gmail.com>.
Hi Romain,

As I'm looking at the 1.1 spec candidate list, I remembered this e-mail.

The majority of your ideas have not already been raised, so just wanted to
encourage you to do so by opening a bug
https://java.net/bugzilla/enter_bug.cgi

I'll save you some time by noting some that were already opened:


On Thu, Dec 18, 2014 at 1:37 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:

>
> - Java API to define batches, I expect something like what was done
> with Jsf to build flows, in 2 words a "registration" event where we
> can use a batch builder to add batches - should of course works with
> CDI. Idea is basically 0 xml.
>

https://java.net/bugzilla/show_bug.cgi?id=4991


- A way to wait an execution (caricaturally an execution would be
> linked to a countdownlatch we can await()).
>

https://java.net/bugzilla/show_bug.cgi?id=7284
(though not specifically with the countdownlatch)

- why not a JAXRS front for JobOperator since JAXRS is in web profile now
>

Sounds new.


> - more CDI integration: @Inject JobOperator op; (just to align on
> programming model but clearly not a blocker) and scopes: @StepScoped,
> @JobScoped, @ChunkScoped at least without thinking more. Maybe also
> CDi events for event corresponding to current listeners
>

I don't see one open for the scopes.  I'd probably open one myself.
@Inject JobOperator is:
https://java.net/bugzilla/show_bug.cgi?id=5075



> - wonder if we could get some conversion between components. If a
> reader returns a Foo then a processor reads a bar could the conversion
> Foo->Bar be defined outside JBatch components (be done automatically
> said otherwise)
>

Not really sure what you mean

- you can look batchee-extras, we provide few utilities, some could be
> surely added to the spec like BufferedItemReader
>

Seems new.


> - async processing (writer would then wait on Futures but at least
> processing could be done in parallel)
>

Seems new.


> - integration with bean validation (like JAXRS parameters surely)
>

I was thinking of bean validation on injection properties though I don't
think we opened an issue yet (I will at some point)...not sure what you
mean in saying "like JAXRS parameters"


> - chaining: I want to call a chain of 5 processor or I read from 2
> writers etc..., how do I "aggregate" my components out of the box?
>
>
New.

---

Having said that, there are some I'm already leaning against to various
degrees.     E.g. the XML-less job was specifically rejected by the
original EG in 1.0.    The utilities would have to be very "final" to be
worth standardizing..... haven't looked at the extras much, but not sure I
think BufferedItemReader is doing enough to bother.

So I don't want to seem like I'm encouraging you to open them up so I can
shoot them down on the public spec list.    OTOH, trying to keep the spec
determinations on the spec list so not trying to give too strong an opinion
here.

Thanks
Scott

Re: Batch 1.1 spec kickoff

Posted by Scott Kurz <sk...@gmail.com>.
Romain,

Thanks for the idea... some have come up before and some look new to me.

Anyway, I hope you can find the time to continue to think about it and join
us on the spec mailing list in the New Year!

Scott

On Thu, Dec 18, 2014 at 1:37 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
>
> Hi Scott,
>
> Here my (Xmas) wish list!
> - Java API to define batches, I expect something like what was done
> with Jsf to build flows, in 2 words a "registration" event where we
> can use a batch builder to add batches - should of course works with
> CDI. Idea is basically 0 xml.
> - A way to wait an execution (caricaturally an execution would be
> linked to a countdownlatch we can await()).
> - why not a JAXRS front for JobOperator since JAXRS is in web profile now
> - more CDI integration: @Inject JobOperator op; (just to align on
> programming model but clearly not a blocker) and scopes: @StepScoped,
> @JobScoped, @ChunkScoped at least without thinking more. Maybe also
> CDi events for event corresponding to current listeners
> - wonder if we could get some conversion between components. If a
> reader returns a Foo then a processor reads a bar could the conversion
> Foo->Bar be defined outside JBatch components (be done automatically
> said otherwise)
> - you can look batchee-extras, we provide few utilities, some could be
> surely added to the spec like BufferedItemReader
> - async processing (writer would then wait on Futures but at least
> processing could be done in parallel)
> - integration with bean validation (like JAXRS parameters surely)
> - chaining: I want to call a chain of 5 processor or I read from 2
> writers etc..., how do I "aggregate" my components out of the box?
>
>
> Surely much more but it starts to be late here ;)
>
>
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-18 19:26 GMT+01:00 Scott Kurz <sk...@gmail.com>:
> > Just wanted to draw your attention to the kickoff of the next round of
> spec
> > work, as I mentioned on our spec mailing list.
> >
> > https://java.net/projects/jbatch/lists/public/archive/2014-12/message/9
> >
> > (Apologies if you're already following that list and this is a
> > duplicate/spam...)
> >
> > Would be interested to hear your thoughts and ideas... as well as receive
> > your contributions and assistance !
> >
> > (That said, I clearly need to do some work on a contributor guide/wiki,
> > which is one of my first intentions, esp. TCK contribution guidance).
>

Re: Batch 1.1 spec kickoff

Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Scott,

Here my (Xmas) wish list!
- Java API to define batches, I expect something like what was done
with Jsf to build flows, in 2 words a "registration" event where we
can use a batch builder to add batches - should of course works with
CDI. Idea is basically 0 xml.
- A way to wait an execution (caricaturally an execution would be
linked to a countdownlatch we can await()).
- why not a JAXRS front for JobOperator since JAXRS is in web profile now
- more CDI integration: @Inject JobOperator op; (just to align on
programming model but clearly not a blocker) and scopes: @StepScoped,
@JobScoped, @ChunkScoped at least without thinking more. Maybe also
CDi events for event corresponding to current listeners
- wonder if we could get some conversion between components. If a
reader returns a Foo then a processor reads a bar could the conversion
Foo->Bar be defined outside JBatch components (be done automatically
said otherwise)
- you can look batchee-extras, we provide few utilities, some could be
surely added to the spec like BufferedItemReader
- async processing (writer would then wait on Futures but at least
processing could be done in parallel)
- integration with bean validation (like JAXRS parameters surely)
- chaining: I want to call a chain of 5 processor or I read from 2
writers etc..., how do I "aggregate" my components out of the box?


Surely much more but it starts to be late here ;)





Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2014-12-18 19:26 GMT+01:00 Scott Kurz <sk...@gmail.com>:
> Just wanted to draw your attention to the kickoff of the next round of spec
> work, as I mentioned on our spec mailing list.
>
> https://java.net/projects/jbatch/lists/public/archive/2014-12/message/9
>
> (Apologies if you're already following that list and this is a
> duplicate/spam...)
>
> Would be interested to hear your thoughts and ideas... as well as receive
> your contributions and assistance !
>
> (That said, I clearly need to do some work on a contributor guide/wiki,
> which is one of my first intentions, esp. TCK contribution guidance).

Re: Batch 1.1 spec kickoff

Posted by Scott Kurz <sk...@gmail.com>.
Mark,
This will be just a MR

On Thu, Dec 18, 2014 at 1:52 PM, Mark Struberg <st...@yahoo.de> wrote:
>
> Hi Scott!
>
> Txs for the info!
> Will there be a new JSR or is this handled as a MR?
>
>
> LieGrue,
> strub
>
>
>
>
>
> > On Thursday, 18 December 2014, 19:27, Scott Kurz <sk...@gmail.com>
> wrote:
> > > Just wanted to draw your attention to the kickoff of the next round of
> spec
> > work, as I mentioned on our spec mailing list.
> >
> > https://java.net/projects/jbatch/lists/public/archive/2014-12/message/9
> >
> > (Apologies if you're already following that list and this is a
> > duplicate/spam...)
> >
> > Would be interested to hear your thoughts and ideas... as well as receive
> > your contributions and assistance !
> >
> > (That said, I clearly need to do some work on a contributor guide/wiki,
> > which is one of my first intentions, esp. TCK contribution guidance).
> >
>

Re: Batch 1.1 spec kickoff

Posted by Mark Struberg <st...@yahoo.de>.
Hi Scott!

Txs for the info!
Will there be a new JSR or is this handled as a MR? 


LieGrue,
strub





> On Thursday, 18 December 2014, 19:27, Scott Kurz <sk...@gmail.com> wrote:
> > Just wanted to draw your attention to the kickoff of the next round of spec
> work, as I mentioned on our spec mailing list.
> 
> https://java.net/projects/jbatch/lists/public/archive/2014-12/message/9
> 
> (Apologies if you're already following that list and this is a
> duplicate/spam...)
> 
> Would be interested to hear your thoughts and ideas... as well as receive
> your contributions and assistance !
> 
> (That said, I clearly need to do some work on a contributor guide/wiki,
> which is one of my first intentions, esp. TCK contribution guidance).
>