Still digesting what you wrote...
Me too!
SAXTransformer.FACTORY_ROLE
Does this mean "Give me SAXTransformer as a Factory"?
I think it does.
Is it some standard naming convention used - like:
String ROLE = "my.Component"; String FACTORY_ROLE = ROLE + "Factory";
that the container can pick up and deliver a factory? Much
like the ROLE + "Selector" we used to have (but useful this time)?
It could be. What do you think? I think naming conventions like we currently have are not a very good thing to rely on (remember the whole urn debate? ugh.), and we probably shouldn't introduce more, but I also thought they did clear up the example a little. It saved eight characters, one line, and one string concatenation (or something like that).
In general, I'm more and more convinced that instead of splitting components between different lifestyles - ThreadSafe, SingleThreaded, Pooled - we should split them along stateful/stateless.
<soapbox>
I'll go further -- the container should not be thinking about lifestyles. What kind of "lifestyle" seperation or decomposition makes sense seems to depend a whole lot on the context. Lifestyles need to be fully pluggable.
And how do you make things pluggable? By using a plugin. Just like you associate Handlers with components in fortress, or ComponentAdapterFactories with components in PicoContainer, or Adapters with components in jicarilla. You need to give the plugin so much power that it can implement any lifestyle. Once you do, all you have to do is provide some sensible defaults and some (simple) base plugins. How you split the lifestyles in those plugins doesn't matter that much. You'll be able to change the decision later on.
We need to design less ("the next big architecture will be about small architecture" -- Yours Truly), and one way to design less is to simply not make the decision how lifestyle should be split. Or even making the decision that "lifestyle" is a useful abstraction.
I remember a big lifestyle debate or two in the past (when we were looking at using containerkit for fortress, and we wanted to put lifestyle concepts in the kit, and it all just didn't make any sense when looked at from a phoenix viewpoint). PD and Berin made some nice tables of possible decompositions, I think Stefano did a dimension analysis or three.
Took a week or four. There was never agreement.
In pico, they (Jon Tirsen IIRC) took a look at different kinds of scoping ("thread", "classloader", "request", "jvm", "blahblah"), figured out that scoping is always associated with something, came up with something dubbed ObjectReference that allows association and/or caching of instances with arbitrary scopes, implemented a few common ones, and changed 0 lines in the TCK unit tests.
That's a powerful setup. Evolvable software. Looking at doing something like that in fortress, the lifestyle abstraction assumptions get in the way.
</soapbox>
Regardless of all that, I probably do agree :D
-- cheers,
- Leo Simons
----------------------------------------------------------------------- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles & Opinions -- http://articles.leosimons.com/ ----------------------------------------------------------------------- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
