On 3/16/07, Glynn, Eoghan <[EMAIL PROTECTED]> 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
