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> 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] On Behalf Of Guilherme Silveira
>> Sent: Dienstag, 5. Juli 2011 20:41
>> To: 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>
>> 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] On Behalf Of Guilherme
>> Silveira
>> >> Sent: Dienstag, 5. Juli 2011 20:15
>> >> To: 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] 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(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>
>> >> >> 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] 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>
>> >> >> >> 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
>> >> >> >> >
>> >> >> >> >
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>