> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
>
> The idea is that MicroCont will run only the simplest components, and
> *must* avoid duplicating definitions-semantics.
> It should not propagate informal component model, and I think
> that Leo
> Sutic agrees with this.
> If you need more, get the next-level container.
No. The idea is this:
MicroContainer should allow Avalon components
to be used without any committment to Avalon architecture.
That is, realize the "no strings attached" goal.
It should also be extremely easy to use, follow Java idioms whenever
possible, etc. I wanted to enable people to use Avalon components in the
same way as they use standard Java classes.
The "upper limit" in functionality for MicroContainer is therefore
defined in terms of the degree of committment to a particular
architecture by the user. I draw the line at requiring XML config files
and assembly descriptors. If you can not get your component via a static
factory method, without having to specify any config files, then it is
not part of MicroContainer's scope.
That it would only run the simplest components was something of an
implication, and not a goal in itself.
After looking at Merlin, I think MicroContainer's goal can be realized
better via it.
Fortress and Phoenix are very powerful, but are absolute nightmares to
start up. You need assembly files, config files etc. etc. All of that,
to run a single simple component. This is how you obtain a
DataSourceComponent in MicroContainer:
DataSourceComponent ds = DataSourceFactory.getDataSource(
driver, // JDBC Driver
dbUrl, // Database URL
userName, // user name
password, // user's password
null, // Connection keep-alive command (none)
1, // Minimum number of connections in pool.
3, // Maximum number of connections in pool.
-1, // Connection timeout (disabled)
true, // Auto commit
false, // Using oracle
null); // Override name of connection class (null ==
use default).
What you get back is a proxy that will dispose the component properly
when GC'd, that can work as a factory to enable you to handle components
with dependencies, and so on. No need to specify config files. Nothing
of that. Just call your factory method just like you are used to do to
obtain a SAX parser and MicroContainer will take care of the rest for
you.
If something like this can be realized via Merlin, then that's better.
And just one final statement: MicroContainer handles dependencies. It
just does not assemble anything automatically. You handle dependencies
by connecting several MicroContainer instances, instead of, like Merlin,
load all dependencies into one container.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
