a) Proxy Handling in Fortress Currently it's possible to define/configure if/how Fortress is creating a proxy for a component. I'm wondering if this flexibility is really required. I think we should always create a proxy.
flexibility is nice, but comes at the cost of increased code complexity (with fortress you don't just choose between proxying or not, you choose between a possible n proxy implementations which need to be consistently used).
In pico the proxying choice is deferred to the handler (ie the ComponentHandler in fortress-speak), which means you can use things like the delegate pattern. It would be nice to set something like that up.
- Performance
I don't believe proxies could ever increase performance. In your example, you can create a non-proxy Entry object or Helper (or something like that), ie like phoenix, which is more perfomant than proxying.
- Better Support for non thread-safe components. See below.
yes.
Now, by always creating a proxy we can remove/clean up some code in Fortress and it gets a little bit smaller as well :)
WDYT?
before we do that we should get in place a more modern and more efficient proxy helper (ie CGLIB). Brian McCallister, Leo Sutic, Howard L. Ship are some of the people I know that have done this.
b) Pooling (or handling of non thread-safe components)
the big one. I've blogged about this several times. I'll go link-hunting in the morning. Suffice to say I agree with you and with PeterD (ie the ReleaseUtil thing is nice; ServiceManager.release() could of course be used for the same basic idea even if it is perhaps less elegant), yes, it can be done, yes, it can increase perfomance, and yes, it can be done safely.
I got halfway through implementing this for pico (using a ReleaseUtil 'n stuff). Leo Sutic has an in-house setup for this around ServiceManager.
I conclude from the docs, that e.g. HiveMind is doing it this way.
sort-of.
WDYT?
yes. I want this.
- LSD
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
