Hi Guilherme
I saw the code and saw the opportunity to highlight what I saw a problem
with that approach -
But sorry for hijacking this thread - I think it happens sometimes :-)
Sergey
> Ho Sergey
>
> I understand and it makes total sense. In a process you cant expect
> everything to return what you wanted. Thats why navigatin through remote
> proxied for rest also seem weird.
>
> But is it somehow connected with the question in this thread?
>
> regards
>
> Guilherme Silveira
>
> On Jul 20, 2011 10:46 AM, "Sergey Beryozkin" <sberyozkin_at_talend.com
> <mailto:sberyozkin_at_talend.com>> wrote:
> > Hi Guilherme,
> >> Sure! My bad not to include any example. While writing the example (see
> >> below), I realized that the once proposed "Link" type (with its
> factory)
> >> would do it, if I am not wrong.
> >>
> >> Here is the example:
> >>
> >> Take any process that navigates through a set of URIs, as in a process
> >> that is executed in 4 steps, and you want to execute the same process
> >> for the 5 different entry points. For example: I want to query
> different
> >> providers about some information. So:
> >>
> >> client = ...;
> >> for(entry : entries) {
> >> result = process1(entry, client.addHeadersForThisRequestA())
> >> result = process2(result.link("a").addHeadersForThisRequestB())
> >> result = process3(result.link("b").addHeadersForThisRequestC())
> >> result = process4(result.link("c").addHeadersForThisRequestD())
> >> result = process5(result.link("d").addHeadersForThisRequestE())
> >> }
> >>
> >> Every step is based on a link. not an URI. So if the Link type as
> >> proposed earlier provides the same configuration interface as Resource
> >> (and the Client), it should be ok.
> >>
> >
> > The above looks nice - but what happens if result.link("a") returns
> null ?
> > I'm not trying to be negative here, just think the fluent style works
> > nice when the builder state is under control, the above is conditional
> > on the presence of "a", etc.
> >
> > Thanks, Sergey
> >
> >> Regards
> >>
> >> Guilherme Silveira
> >> Caelum | Ensino e Inovação
> >> http://www.caelum.com.br/
> >>
> >>
> >> On Thu, Jul 14, 2011 at 2:15 PM, Markus KARG <markus_at_headcrashing.eu
> <mailto:markus_at_headcrashing.eu>
> >> <mailto:markus_at_headcrashing.eu <mailto:markus_at_headcrashing.eu>>> wrote:
> >>
> >> Can you give a real-world scenario when something complex like that
> >> will be
> >> needed?
> >>
> >> > -----Original Message-----
> >> > From: guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>
> >> <mailto:guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>>
> >> > [mailto:guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>
> >> <mailto:guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>>] On Behalf Of Guilherme Silveira
> >> > Sent: Mittwoch, 13. Juli 2011 14:24
> >> > To: jsr339-experts_at_jax-rs-spec.java.net
> <mailto:jsr339-experts_at_jax-rs-spec.java.net>
> >> <mailto:jsr339-experts_at_jax-rs-spec.java.net
> <mailto:jsr339-experts_at_jax-rs-spec.java.net>>
> >> > Subject: [jsr339-experts] Re: [ClientAPI] Naming Proposals
> >> >
> >> > > I do not see a need for that.
> >> > And if the client needs to set 3 config for N resources, but not for
> >> > every resource, he will do:
> >> >
> >> > Resource 1st = ...
> >> > Resource 2nd = ...
> >> > ...
> >> > Resource nth = ...
> >> >
> >> > config(1st, 2nd, ... nth);
> >> >
> >> > void config(List<Resource> rs) {
> >> > for(Resource r:rs) {
> >> > r.enableFeature(first);
> >> > r.enableFeature(second);
> >> > r.withHeaders...;
> >> > }
> >> > }
> >> >
> >> > Something like that?
> >> >
> >> > Regards
> >> >
> >> > Guilherme Silveira
> >> > Caelum | Ensino e Inovação
> >> > http://www.caelum.com.br/
> >> >
> >> >
> >> >
> >> > On Tue, Jul 12, 2011 at 2:57 PM, Markus KARG
> >> <markus_at_headcrashing.eu <mailto:markus_at_headcrashing.eu>
> <mailto:markus_at_headcrashing.eu <mailto:markus_at_headcrashing.eu>>>
> >> > wrote:
> >> > > I do not see a need for that.
> >> > >
> >> > >> -----Original Message-----
> >> > >> From: guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>
> >> <mailto:guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>>
> >> > >> [mailto:guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>
> >> <mailto:guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>>] On Behalf Of Guilherme
> >> > Silveira
> >> > >> Sent: Dienstag, 12. Juli 2011 16:58
> >> > >> To: jsr339-experts_at_jax-rs-spec.java.net
> <mailto:jsr339-experts_at_jax-rs-spec.java.net>
> >> <mailto:jsr339-experts_at_jax-rs-spec.java.net
> <mailto:jsr339-experts_at_jax-rs-spec.java.net>>
> >> > >> Subject: [jsr339-experts] Re: [ClientAPI] Naming Proposals
> >> > >>
> >> > >> Hi Markus,
> >> > >>
> >> > >> I got it now. A detached Invocation-alike instance support for
> >> > >> Resource based mappings. Wouldn't it be better to make it more
> >> > generic
> >> > >> and support any kind of detached support then? i.e.:
> >> > >>
> >> > >> > ClientFactory f = ClientFactory.instance();
> >> > >> > f.enableFeature(x);
> >> > >>
> >> > >> > Client client = ClientFactory.create()
> >> > >> > c.enableFeature(y);
> >> > >>
> >> > >> > Invocation i = client.post();
> >> > >> > i.enableFeature(z)
> >> > >>
> >> > >> > DetachedInvocation i = Prepare.from(URL);
> >> > >> > i.enableFeature(z);
> >> > >>
> >> > >> > i.queue(r);
> >> > >>
> >> > >> where
> >> > >> DetachedInvocation := Invocation - execution methods
> >> > >>
> >> > >> So it gives support not only to Resource based warming up of
> >> > objects,
> >> > >> but anything like:
> >> > >>
> >> > >> zippingHeaders = Prepare.withHeaders(...)
> >> > >> commonFeatures = Prepare.with(Feature1.class).with(Feature2.class)
> >> > >>
> >> > >> Invocation i = ClientFactory.create().get().post(); // the same as
> >> > your
> >> > >> code
> >> > >>
> >> > >> i.queue(zippingHeaders.with(commonFeatures));
> >> > >>
> >> > >> Regards
> >> > >>
> >> > >> Guilherme Silveira
> >> > >> Caelum | Ensino e Inovação
> >> > >> http://www.caelum.com.br/
> >> > >>
> >> > >>
> >> > >>
> >> > >> On Wed, Jul 6, 2011 at 4:22 PM, Markus KARG
> >> <markus_at_headcrashing.eu <mailto:markus_at_headcrashing.eu>
> <mailto:markus_at_headcrashing.eu <mailto:markus_at_headcrashing.eu>>>
> >> > >> wrote:
> >> > >> > (using fancy method names, not aligned with any proposal)
> >> > >> >
> >> > >> > ClientFactory f = ClientFactory.instance();
> >> > >> > f.enableFeature(x); // enables feature x for all clients to
> >> > prevent
> >> > >> > repeating
> >> > >> > Client client = ClientFactory.create()
> >> > >> > c.enableFeature(y); // enables feature y for this client only,
> >> > other
> >> > >> clients
> >> > >> > must not have this enabled.
> >> > >> > Invocation i = client.post();
> >> > >> > i.setHeader(...);
> >> > >> > Resource r = Resource.from(URL);
> >> > >> > r.enableLogging(); // all access to this resource must be
> >> logged,
> >> > but
> >> > >> not
> >> > >> > other resources
> >> > >> > i.queue(r);
> >> > >> >
> >> > >> > If you do it with less interfaces, you would enable logging on
> >> > other
> >> > >> > resources, too, or you have to repeat the logging enablement
> >> with
> >> > all
> >> > >> > resources (creates log clutter), or you would enable feature
> >> y on
> >> > all
> >> > >> > clients (even if not wanted there, especially in server side
> >> > client
> >> > >> API
> >> > >> > usage where another client is needed for a different
> >> application),
> >> > or
> >> > >> you
> >> > >> > would have to repeat enableFeature(x) for all clients.
> >> > >> >
> >> > >> > So, how you like to solve that?
> >> > >> >
> >> > >> > Regards
> >> > >> > Markus
> >> > >> >
> >> > >> >> -----Original Message-----
> >> > >> >> From: guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>
> >> <mailto:guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>>
> >> > >> >> [mailto:guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>
> >> <mailto:guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>>] On Behalf Of Guilherme
> >> > >> Silveira
> >> > >> >> Sent: Dienstag, 5. Juli 2011 20:41
> >> > >> >> To: jsr339-experts_at_jax-rs-spec.java.net
> <mailto:jsr339-experts_at_jax-rs-spec.java.net>
> >> <mailto:jsr339-experts_at_jax-rs-spec.java.net
> <mailto:jsr339-experts_at_jax-rs-spec.java.net>>
> >> > >> >> Subject: [jsr339-experts] Re: [ClientAPI] Naming Proposals
> >> > >> >>
> >> > >> >> > Because a user might like to configure *all* requests upon a
> >> > >> resource
> >> > >> >> > without the need to repeat that with each invocation. If you
> >> > use
> >> > >> the
> >> > >> >> URL
> >> > >> >> > class, you cannot do that, since the URL class is not
> >> > >> configurable.
> >> > >> >> I still can't see why he wouldn't be able to do that with 3
> >> > >> >> interfaces, can you show me the code that is possible
> >> within the
> >> > >> >> current approach? And I try to write with three interfaces?
> >> > >> >>
> >> > >> >> Regards
> >> > >> >>
> >> > >> >> Guilherme Silveira
> >> > >> >> Caelum | Ensino e Inovação
> >> > >> >> http://www.caelum.com.br/
> >> > >> >>
> >> > >> >>
> >> > >> >>
> >> > >> >> On Tue, Jul 5, 2011 at 3:20 PM, Markus KARG
> >> > <markus_at_headcrashing.eu <mailto:markus_at_headcrashing.eu>
> <mailto:markus_at_headcrashing.eu <mailto:markus_at_headcrashing.eu>>>
> >> > >> >> wrote:
> >> > >> >> > Because a user might like to configure *all* requests upon a
> >> > >> resource
> >> > >> >> > without the need to repeat that with each invocation. If you
> >> > use
> >> > >> the
> >> > >> >> URL
> >> > >> >> > class, you cannot do that, since the URL class is not
> >> > >> configurable.
> >> > >> >> >
> >> > >> >> >> -----Original Message-----
> >> > >> >> >> From: guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>
> >> <mailto:guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>>
> >> > >> >> >> [mailto:guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>
> >> <mailto:guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>>] On Behalf Of Guilherme
> >> > >> >> Silveira
> >> > >> >> >> Sent: Dienstag, 5. Juli 2011 20:15
> >> > >> >> >> To: jsr339-experts_at_jax-rs-spec.java.net
> <mailto:jsr339-experts_at_jax-rs-spec.java.net>
> >> <mailto:jsr339-experts_at_jax-rs-spec.java.net
> <mailto:jsr339-experts_at_jax-rs-spec.java.net>>
> >> > >> >> >> Subject: [jsr339-experts] Re: [ClientAPI] Naming Proposals
> >> > >> >> >>
> >> > >> >> >> > A resource is something that you can point to using a URL.
> >> > >> >> >> So I really didnt get why the three interfaces dont
> >> solve the
> >> > >> >> problem
> >> > >> >> >> as the code I posted.
> >> > >> >> >>
> >> > >> >> >> Regards
> >> > >> >> >>
> >> > >> >> >> >
> >> > >> >> >> >> -----Original Message-----
> >> > >> >> >> >> From: guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>
> >> <mailto:guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>>
> >> > >> >> >> >> [mailto:guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>
> >> <mailto:guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>>] On Behalf Of
> >> > Guilherme
> >> > >> >> >> Silveira
> >> > >> >> >> >> Sent: Sonntag, 3. Juli 2011 15:31
> >> > >> >> >> >> To: jsr339-experts
> >> > >> >> >> >> Subject: [jsr339-experts] Re: [ClientAPI] Naming
> >> Proposals
> >> > >> >> >> >>
> >> > >> >> >> >> > One might want to apply different sets of features
> >> (like
> >> > >> >> >> filtering,
> >> > >> >> >> >> caching,
> >> > >> >> >> >> > etc.) to one resource.
> >> > >> >> >> >> It seems I didn't quite understand what is being called a
> >> > >> >> "resource"
> >> > >> >> >> >> here. Is it something like:
> >> > >> >> >> >>
> >> > >> >> >> >> Client client = provider.create();
> >> > >> >> >> >> Request r = client.at <http://client.at>
> <http://client.at>(uri);
> >> > >> >> >> >> Request first = r.with(filterA()); // this one will only
> >> > use
> >> > >> >> filterA
> >> > >> >> >> >> Request second = r.with(filterB()); // this one will only
> >> > use
> >> > >> >> filter
> >> > >> >> >> B
> >> > >> >> >> >>
> >> > >> >> >> >> ?
> >> > >> >> >> >>
> >> > >> >> >> >> Regards
> >> > >> >> >> >>
> >> > >> >> >> >> Guilherme Silveira
> >> > >> >> >> >> Caelum | Ensino e Inovação
> >> > >> >> >> >> http://www.caelum.com.br/
> >> > >> >> >> >>
> >> > >> >> >> >>
> >> > >> >> >> >>
> >> > >> >> >> >> On Sun, Jul 3, 2011 at 10:24 AM, Markus KARG
> >> > >> >> >> <markus_at_headcrashing.eu <mailto:markus_at_headcrashing.eu>
> <mailto:markus_at_headcrashing.eu <mailto:markus_at_headcrashing.eu>>>
> >> > >> >> >> >> wrote:
> >> > >> >> >> >> > The problem is that three parts does not match all
> >> > requested
> >> > >> >> >> >> features:
> >> > >> >> >> >> >
> >> > >> >> >> >> > One might want to apply different sets of features
> >> (like
> >> > >> >> >> filtering,
> >> > >> >> >> >> caching,
> >> > >> >> >> >> > etc.) to one resource. This information is neither
> >> bound
> >> > to
> >> > >> the
> >> > >> >> >> >> client
> >> > >> >> >> >> > (unless you create one client per resource) nor to the
> >> > >> request
> >> > >> >> >> >> (unless you
> >> > >> >> >> >> > set the configuration at every other request). So to
> >> > support
> >> > >> >> this,
> >> > >> >> >> >> you need
> >> > >> >> >> >> > the resource as the forth brick in this puzzle. Or you
> >> > just
> >> > >> >> will
> >> > >> >> >> not
> >> > >> >> >> >> support
> >> > >> >> >> >> > that usage pattern and prevent the possibily to add
> >> it at
> >> > >> any
> >> > >> >> >> later
> >> > >> >> >> >> time, as
> >> > >> >> >> >> > the API cannot be changed anymore without breaking
> >> > backwards
> >> > >> >> >> >> compatibility.
> >> > >> >> >> >> >
> >> > >> >> >> >> > Regards
> >> > >> >> >> >> > Markus
> >> > >> >> >> >> >
> >> > >> >> >> >> >> -----Original Message-----
> >> > >> >> >> >> >> From: guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>
> >> <mailto:guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>>
> >> > >> >> >> >> >> [mailto:guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>
> >> <mailto:guilherme.silveira_at_gmail.com
> <mailto:guilherme.silveira_at_gmail.com>>] On Behalf Of
> >> > >> Guilherme
> >> > >> >> >> >> Silveira
> >> > >> >> >> >> >> Sent: Sonntag, 3. Juli 2011 14:38
> >> > >> >> >> >> >> To: jsr339-experts
> >> > >> >> >> >> >> Subject: [jsr339-experts] Re: [ClientAPI] Naming
> >> > Proposals
> >> > >> >> >> >> >>
> >> > >> >> >> >> >> Hi Markus,
> >> > >> >> >> >> >>
> >> > >> >> >> >> >> I can see three distinct elements while requesting:
> >> > >> >> >> >> >>
> >> > >> >> >> >> >> :: Provider => Client => Request
> >> > >> >> >> >> >>
> >> > >> >> >> >> >> A provider provides a client that starts building a
> >> > >> request.
> >> > >> >> The
> >> > >> >> >> >> >> request builts on top of itself until its dispatched.
> >> > >> Finally,
> >> > >> >> on
> >> > >> >> >> >> the
> >> > >> >> >> >> >> response:
> >> > >> >> >> >> >>
> >> > >> >> >> >> >> :: Response
> >> > >> >> >> >> >>
> >> > >> >> >> >> >> I believe this is the simplest I can get. Restfulie is
> >> > >> >> similar:
> >> > >> >> >> >> >> Provider = Restfulie
> >> > >> >> >> >> >> Client = RestClient
> >> > >> >> >> >> >> Request = Request
> >> > >> >> >> >> >> Response = Response
> >> > >> >> >> >> >>
> >> > >> >> >> >> >> The final code can be any of (explosion of methods
> >> or no
> >> > >> >> compile
> >> > >> >> >> >> time
> >> > >> >> >> >> >> check):
> >> > >> >> >> >> >> Provider.create().at(uri).get()
> >> > >> >> >> >> >>
> >> > >> >> >> >> >> or caching objects, with invoke on its parent (apache
> >> > >> commons
> >> > >> >> >> alike,
> >> > >> >> >> >> >> type safe one ntity body etc):
> >> > >> >> >> >> >> client.invoke(preparedRequest)
> >> > >> >> >> >> >>
> >> > >> >> >> >> >> One can break the interface into smaller pieces
> >> and try
> >> > to
> >> > >> >> >> achieve
> >> > >> >> >> >> >> better type compile time checking.
> >> > >> >> >> >> >> I am ignoring the hypermedia part so far (for which I
> >> > would
> >> > >> >> add a
> >> > >> >> >> >> Link
> >> > >> >> >> >> >> and Form interface).
> >> > >> >> >> >> >>
> >> > >> >> >> >> >> Thisis the one I was going to propsoe,but it didnt
> >> seem
> >> > >> >> >> interesting,
> >> > >> >> >> >> is
> >> > >> >> >> >> >> it?
> >> > >> >> >> >> >>
> >> > >> >> >> >> >> Regards
> >> > >> >> >> >> >>
> >> > >> >> >> >> >> Guilherme Silveira
> >> > >> >> >> >> >> Caelum | Ensino e Inovação
> >> > >> >> >> >> >> http://www.caelum.com.br/
> >> > >> >> >> >> >>
> >> > >> >> >> >> >>
> >> > >> >> >> >> >>
> >> > >> >> >> >> >> On Sat, Jul 2, 2011 at 4:56 AM, Markus KARG
> >> > >> >> >> <markus_at_headcrashing.eu <mailto:markus_at_headcrashing.eu>
> <mailto:markus_at_headcrashing.eu <mailto:markus_at_headcrashing.eu>>>
> >> > >> >> >> >> >> wrote:
> >> > >> >> >> >> >> > Experts,
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> > reading the very interesting recent discussion about
> >> > the
> >> > >> >> naming
> >> > >> >> >> of
> >> > >> >> >> >> >> the
> >> > >> >> >> >> >> > client parts, I have to say that I share both
> >> > opinions:
> >> > >> The
> >> > >> >> >> >> >> complexity is
> >> > >> >> >> >> >> > needed to reach the intended feature set and
> >> > flexibility,
> >> > >> >> but
> >> > >> >> >> the
> >> > >> >> >> >> >> current
> >> > >> >> >> >> >> > naming is far from being intuitive. Thus, I'd
> >> like to
> >> > >> >> propose
> >> > >> >> >> just
> >> > >> >> >> >> >> names
> >> > >> >> >> >> >> > (not any different implementation or "revolution").
> >> > Maybe
> >> > >> >> >> picking
> >> > >> >> >> >> >> some of
> >> > >> >> >> >> >> > them can solve the problem. Maybe other experts have
> >> > even
> >> > >> >> >> better
> >> > >> >> >> >> name
> >> > >> >> >> >> >> > suggestions to solve the trouble?
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> > "Engine", "Implementation", "JAXRS" or "REST" -- The
> >> > >> major
> >> > >> >> >> entry
> >> > >> >> >> >> >> point for
> >> > >> >> >> >> >> > separating vendor specifics, providing Client. In
> >> > fact,
> >> > >> >> >> "Provider"
> >> > >> >> >> >> is
> >> > >> >> >> >> >> great
> >> > >> >> >> >> >> > as it is used by JPA already, it is used already
> >> > >> differently
> >> > >> >> in
> >> > >> >> >> >> JAX-
> >> > >> >> >> >> >> RS.
> >> > >> >> >> >> >> > "JAXRS" was inspired by "JAXB", which is a smart,
> >> > static
> >> > >> >> entry
> >> > >> >> >> >> point.
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> > "Client" -- A configurable instance ready to
> >> access a
> >> > web
> >> > >> >> >> resource
> >> > >> >> >> >> >> (provides
> >> > >> >> >> >> >> > invocations).
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> > "Target" -- sorry but 'Link' is just confusing and
> >> > >> >> >> "WebResource"
> >> > >> >> >> >> was
> >> > >> >> >> >> >> not
> >> > >> >> >> >> >> > wanted. Also Link might be needed for Hypermedia API
> >> > >> later
> >> > >> >> in
> >> > >> >> >> this
> >> > >> >> >> >> >> project.
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> > "Invocation", "Call", "MethodExecution" -- Well,
> >> > obvious.
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> > I think everybody agrees that the separation is
> >> > needed,
> >> > >> so
> >> > >> >> the
> >> > >> >> >> >> >> current
> >> > >> >> >> >> >> > dispute should be easy to solve if more experts
> >> share
> >> > >> their
> >> > >> >> >> ideas
> >> > >> >> >> >> >> about the
> >> > >> >> >> >> >> > naming.
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> > About invoke() I understand that it is not smart to
> >> > need
> >> > >> >> >> >> >> get().invoke() vs.
> >> > >> >> >> >> >> > get().queue(), but I do not see that
> >> > >> >> >> >> invoke(invocationFactory.get())
> >> > >> >> >> >> >> or
> >> > >> >> >> >> >> > queue(invocationFactory.get()) would be any better -
> >> > but
> >> > >> >> less
> >> > >> >> >> >> fluent.
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> > Regards
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> > Markus
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >> >
> >> > >> >> >> >> >
> >> > >> >> >> >> >
> >> > >> >> >> >
> >> > >> >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >
> >> > >> >
> >> > >
> >> > >
> >>
> >>
> >
> >