RE: Client API, EPRs [subject got lost last time ...]

["Glynn, Eoghan" <eo...@iona.com>]

 

> 99.9999% of the people will have a Client.

Agreed a lot of folks will use the client. Maybe 99.9999%, maybe any
other percentage you care to pluck from the air.

But I don't see why that justifies making it gratuitously awkward to
avoid using it.

 
> Because of API complexity and inconsistency as I've stated in my other

> emails.

Can you be explicit as to exactly what in the API you consider complex
and/or inconsistent.


> Its not DI/Spring friendly though.

Couldn't a DRE bean just be <ref>erred to from the Conduit bean, if
Spring-loading of the DRE is the issue?

As opposed to wiring it into a new Client bean, thereby forcing the
usage of a Client?

What makes the wiring the DRE bean into the Client bean any more
"DI/Spring friendly" than wiring it into the Conduit bean?

/Eoghan 

Re: Client API, EPRs [subject got lost last time ...]

[Dan Diephouse <da...@envoisolutions.com>]

On 3/16/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
>
> > 99.9999% of the people will have a Client.
>
> Agreed a lot of folks will use the client. Maybe 99.9999%, maybe any
> other percentage you care to pluck from the air.
>
> But I don't see why that justifies making it gratuitously awkward to
> avoid using it.


Its not gratuitously awkward to create your own Destination. You create your
EPR and then your Destination. From the amount of work that is required, it
certainly isn't more than creating a ClientPolicy and setting the EPR on the
ClientPolicy. However it does avoid the things I mention below...

> Because of API complexity and inconsistency as I've stated in my other
>
> > emails.
>
> Can you be explicit as to exactly what in the API you consider complex
> and/or inconsistent.


This: c.getPolicy(ConduitPolicy.class).setDecoupledEndpoint(myEPR)

This has the following affects compared to my proposal
1. Creation of a new ConduitPolicy class - *which is unnecessary*
2. It creates a different way of creating Destinations that is only used
sometimes. You're saying that users should use the ClientPolicy to set up
the ReplyTo and for any other decoupled destinations (like FaultTo or
AcksTo), they have to create it using the DestinationFactory API.
3. It requires an additional Conduit method - Conduit.getBackChannel() -
which complexifies the Conduit concept.
4. Creates a non DI friendly API (see below)

> Its not DI/Spring friendly though.
>
> Couldn't a DRE bean just be <ref>erred to from the Conduit bean, if
> Spring-loading of the DRE is the issue?
>
> As opposed to wiring it into a new Client bean, thereby forcing the
> usage of a Client?
>
> What makes the wiring the DRE bean into the Client bean any more
> "DI/Spring friendly" than wiring it into the Conduit bean?


c.getPolicy(ConduitPolicy.class) is not spring friendly at all. You would
have to create a <map>, <entry>, a clientpolicy bean, and then set the
decoupled EPR. I'm looking for a more bean oriented approach. I want to be
able to create a destination and inject it directly into my client.

You're also nesting the destination unnecessarily inside the conduit. What
if I just want to change the decoupled destination? Adding a ConduitPolicy
bean is unnecessary.

- Dan

-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog