Well I do test driven development. Therefore I am used to express and program using the registry object. It seams natural and allows even things like check if a given service is available or not (ok I can use the story board or check the properties of the service proxy). It just seams natural now and I like to check for some symbols and alike. Even doing some dynamic configuration.
At the end I need it to be injected in my test pages first place. I currently work around this but its not good. Many tapestry instances would allow me to test the code from the view of two independent nodes collaborating. Currently the only chance I have is test this in isolation or start a second JVM (which I am going to do later in the project). But having a second JVM one can not easily debug two instances at the same time. So actually it is limiting. Also another scenario is using embedded tapestry in other servers like Vertx or even have two distinct tapestry servlets running and alike. Its just a unnecessary limitation. If one might consider this to change in Tapestry 6 Here is a simple way. Let a thread to be owned by a tapestry instance. Therefore if you do something like tapestry.newThread() a thread local is set within the new thread and mark this thread to be owned by a specific instance. This would also improve the injection capability and everyone could likely use something like Tapestry.getCurrentInstance() to find the instance owning the current thread. So no need for singletons and static references anymore. And yes currently the tapestry instance is represented by registry which gives the chance to introduce a real Tapestry instance representation without breaking the backward compatibility. So maybe one like to add this to tapestry 5.5? It would be huge for tapestry to simplify or better enabling test driven development because of its superiourity<https://www.google.de/search?&q=superiourity>;-). I spend two weaks to get everything in place to start test driven development and I am still improving it every now and then spending some additional hours on it - and thats an afford that should not be necessary. 2013/10/19 Muhammad Gelbana <m.gelb...@gmail.com> > I don't know how to inject the Registry as a service, but I'd like to ask, > why ? > And what's the flaw in having only one Tapestry instance per JVM ? > > *---------------------* > *Muhammad Gelbana* > http://www.linkedin.com/in/mgelbana > > > On Sat, Oct 19, 2013 at 11:21 AM, Martin Kersten < > martin.kersten...@gmail.com> wrote: > > > Hi there, > > > > I just wonder why the registry is not available as a service. > > > > Doing all those test writing I got used to handle the Registry directly. > > Since the Registry represents the IOC for me, I just wonder why it is > ment > > to that the registry can not directly be injected (or do I miss something > > here). > > > > The only reference I found was that the Registry adds itself to the > > SerializationSupport. Which by checking the references looks like a > relict > > and should be removed from the code. It looks like that tapestry tries to > > impose a single tapestry instance per JVM which seams to me like a design > > flaw. (If you collect things to change for Tapestry 6 maybe one should > add > > that multiple instances of tapestry should be possible per JVM so no more > > use of static references). > > > > So unitl I missed something, I just wonder why I can not do something > like: > > > > ServiceImpl(Registry){...} > > > > I can provide it easily by doing something like: > > > > binder.bind(RegisteryReference.class); > > > > --- > > registery.getService(RegisteryReference).setRegistery(registry); > > > > And then I inject the reference in my services. The reference uses a weak > > link to ease gc on shutdown. > > > > (Or I just bind a registry wrapper that delegates the registry > interaction > > towards the real registry once it is created). > > > > Any comments why this is not available by default or did I missed the > point > > here and its already in place? > > > > > > Cheers, > > > > Martin (Kersten), > > Germany > > >
