Geert Bevin wrote:
* currently it only makes it possible to support singletons
One way of easily adding support for deferred instantiation is by
adding support for PropertyValue objects. You could then add one that
creates now instances every time the value is obtained.
Okay, that seems simple enough. I didn't personally have any need for
non-singleton dependencies but it's no big deal to add in case other
people need it.
* relies on properties files
It would be nice if people could set this up by simply extending your
DependencyParticipant and adding the mappings with regular Java calls.
The properties file support would then be a wrapper that uses this.
Yeah, I'm not too nuts about the properties file thing, but it was the
shortest route to a working system when I wrote this class last week. At
the very least it should use XML-based configuration to be consistent
with the rest of RIFE.
I hadn't thought about Java-based mapping configuration. That should be
doable, and it will certainly make things cleaner. It will require a
tweak to the way I do the dependency injection, though; right now the
participant runs in two passes (one to create all the bean instances,
one to inject them into each other) but obviously that's not workable
with Java-based configuration since you would never know when to end the
first pass. And in fact there might be new beans appearing much later.
But it's easy enough to do the injection incrementally as new beans are
added. (Using "bean" in the Spring sense of "an object the IoC system
knows about.")
So you mean, whenever the classloader decides that thing need to be
reloaded because some of the element or site assets have changed, it
should rebuilt the properties that your participant creates? This
shouldn't be difficult to add using SiteListeners. I just don't want
to tie this into RIFE as a hard-wired feature that requires the
presence of the participant. So it need to auto-detect / auto-adapt.
Yes, I sort of mean that, but you could add the list of bean classes to
the list of assets RIFE is monitoring for changes. It could do its
auto-recompile, allow-signature-changes thing with those classes just
like it does for elements. (Via a timer or a periodic scan when a
request comes in, etc.) If one of them changes, discard all the old
instances and run the setup logic again under the classloader that has
the new version of the class. I think you should be able to do that
without a full "reload the site" pass.
That is, if my assumption about how the RIFE classloader works is
correct. Haven't actually looked at it yet.
This would obviously require that application code not keep long-lived
references to the IoC-managed objects, but I think that's a totally
reasonable restriction.
That's not doable just with SiteListeners, right?
What do you think?
Sounds good -- now all I need is a 36-hour day so I can do all that and
my real job too! :)
-Steve
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
