Hello Patrick, All, Concerning use case of swapping services, it's actually happening already, and quite frequently, imagine singleton service instance with "threaded" services injected inside. So my point it that swapping of the services is already there, however it's happening not on the layer of fields in the service implementation but on the level of proxies (that's how it works in T4 (HM1.1) and I assume in T5). So singleton service has a reference to proxy, but proxy finds the implementation of the service dynamically based on the Thread where it is called. If we are talking about the usecase that in case system (JVM) is overloaded proxy may decide to forward the calls to the remote JVM in the cluster, and I guess this usecase is already implemented.
Renat On 17/11/2007, Patrick Moore <[EMAIL PROTECTED]> wrote: > > Hi -- > > On Nov 17, 2007 8:41 AM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > > On Nov 16, 2007 10:39 PM, Patrick Moore <[EMAIL PROTECTED]> wrote: > > > Hi Howard -- > > > I disagree with philosophy of forcing people to have the services only > > > injected via constructors because: > > > > > > 1. it results in a monster constructors for some key services. > > > > I would say that those key services may be insufficiently factored > > into smaller cooperating services. Seperation of concerns! > > > > Actually just the opposite! We have facade-pattern services that present > a > unified interface point to the "outside" code. But under the hood the > facade > service delegates to the smaller services. > > Of course we use the facade pattern so that we can isolate changes to the > underlying services. But those facade-pattern services talk to many other > services. > > > > > 5. You are assuming that it is unconceivable for services once > wired > > > together to ever want to be rewired - and this is not the case. > > > > I see that as a whole can of worms. I strongly think that static > > structure / dynamic behavior extends into the services tier. > > > > Oh I understand that as well -- and its not something I suggest doing as a > normal course. The major uses I am thinking about are around swapping out > local services for a remote implementation of a service. Not your normal > use > case I grant you! And I am going to do everything I can to design an > alternative solution. But having to bring down the server in order to > reconfigure it, or to require programmatic changes to do reconfiguration > seems bad. > > > > > > > > But at the end of the day - why be dogmatic about this? > > > > Because I'm a very stubborn person? > > > Wouldn't know! But I complement your stubbornness wrt at least one thing > -- the tapestry error messages are far superior to many other > packages out > there, open-source or otherwise. > > > > > > > Points well taken. We could definitely do something like Guice and > > allow the Inject annotation on methods as well as method parameters, > > to indicate a method which represents a point of injection. > > > > Thanks for listening... > > > -Pat > -- Best regards, Renat Zubairov
