>>>>> "Peter" == Peter M Goldstein <[EMAIL PROTECTED]> writes:
Peter> Finally, I don't know much about the situation where the
Peter> Avalon container is embedded inside another container that
Peter> exposes DataSources to its hosted applications (i.e. Phoenix
Peter> inside JBoss, Merlin inside Tomcat), but I don't believe
Peter> those DataSources are made available to Avalon components.
What I would do in such case, I would write an implementation of
DataSourceComponent that uses JNDI lookup and use that component to
provide my components with a data source.
Peter> First, there is no standard way for a component to access a
Peter> DataSource. There is an implicit binding to another
Peter> component in the system. So if I write a component for one
Peter> application, and want to reuse it in another, I need to
Peter> ensure that the same method is being used by the second
Peter> application to expose DataSources.
It seems to me that the DataSourceComponent and the associated selector
are the "de facto" standard in Avalon world for obtaining a data source.
And the binding is very explicit, you have to declare it in .xinfo. On
the issue of mix-n-matching, it is very easy to write a component
implementing DataSourceComponent around pretty much any DataSource
provider. Be it JDBC3 DataSource or whatever else.
Peter> This is a coding and not
Peter> a configuration level issue. Most other types of containers
Peter> have made this a configuration level issue using JNDI.
It is yet to be proven that those other containers are better ;-)
Peter> Second, in this set up one generally has to ensure that the
Peter> component supplying the database connections is at the base
Peter> of the dependency tree. In most systems, data stores are
Peter> fundamental. So if a database is being used, it's important
Peter> that they be available early. This isn't a huge deal, but it
Peter> simply adds an extra layer to the dependency declarations.
Doesn't container automatically handle the ordering issue?
Peter> Third, the problems with the ill-defined Context lookup
Peter> impact this question. If the Context is to be used to lookup
Peter> data sources, it's not clear how to do that in a standard
Peter> way.
I am not convinced that DataSources need such preferential treatment as
to define a special lookup mechanism.
Peter> Fourth, I would imagine there would be situations where the
Peter> container may want access to data sources for its own
Peter> purposes (i.e. logging). In the current setup
Peter> container-configured data sources and component-configured
Peter> data sources must be distinct. This seems sub-optimal.
On the contrary, I would say that this is a worthwhile separation. This
logging database connection should not be mixed with the one used by the
hosted components.
So, my summary is: what you are bringing up is not an issue for me
(maybe just yet).
Thanks
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
