Re: Dynamic services + multi db patch

[Howard Lewis Ship <hl...@gmail.com>]

This looks like some interesting work ... yes, the names get
confusing, as the compile phase starts extending into the runtime.
I'm working on a side project where I use "concrete" for traditional
classes (via javac) and "plastic" for runtime created (or enhanced)
classes.

In any case, I'm afraid that "dynamic" will work, as opposed to normal
services that are discovered statically (via naming convention for
build methods, or via ServiceBinder.bind() ).

On Sun, Oct 24, 2010 at 7:19 PM, Tom van Dijk <to...@tvandijk.nl> wrote:
> Hi Howard,
>
> as far as I can see, things seem getting towards completion.
>
> I may be missing stuff right now in my head, because it is getting pretty
> late here (4:10 AM)
>
> I'd like to know whether you would like this dynamic stuff to be called
> "dynamic" or "runtime". The semantics don't quite match with the usual
> concept of dynamic, because after registry startup no service can be added
> or removed. "Runtime services" might be a better name, which makes the
> current services "compile-time services".
>
> I asked Josh to pull from my git again and put it on codereview as he did
> earlier. If you use git, feel free to pull
> git://hetdiana.homeip.net/tapestry5.git branch hibmod2. It includes the two
> commits that I put on JIRA (1320 and 1321). It's based on the trunk I just
> pulled from you.
>
> In IoC I included a couple of throw RuntimeException()s. Perhaps that
> would be cleaner if the texts are moved to IOCMessages. Also, there may be

No, the whole IOCMessages thing was a regrettable hold over from
HiveMind which was for JDK 1.3 so it didn't have String.format().  I
should never have bothered with that for T5 which was always based on
JDK 1.5.  In fact, as I work on code, I've been stripping out the use
of static XXXMessages classes.


> spots in the IoC that lack methods for <interface+markers> rather than
> <serviceId> references. The one that was most important I added to the
> ObjectLocator in the patch on JIRA (TAP5-1321), but there may be more
> places where this is useful, for except configuration.addInstance(). I also
> didn't further consider reloading of services and whether that's impacted
> in some way by my patch.
>
> I did note that I sometimes had to do "mvn clean install" twice or thrice
> for it to work. This was on 2-3 test cases, one of them being something
> with "reload" in its name and another with concurrent barriers. The
> randomness of this indicates to me there might be some correct
> multithreading missing somewhere.

I don't see this ever happen on my Mac, but it happens pretty often on
Hudson (which builds using Ubuntu). It's much more likely an error in
the test than in the code being tested.

> Also, there are complaints about multiple
> registries, which I see in the Hudson builds as well. Perhaps the Registry
> isn't shut down in every test case? I didn't further investigate this.
>

I've been meaning to track down the cause of the "multiple registries"
error as well.


> Regards,
>
> Tom.
>

Thanks for the effort and patches, I'm sure we'll find a way to get
this into 5.3 but it's too late in the 5.2 cycle.  Fortunately, I
really, really think this time that 5.3 will be out very quickly.

-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org