avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Steuck <greg-avalon-...@nest.cx>
Subject Re: Avalon Containers and DataSources
Date Tue, 04 Mar 2003 07:59:49 GMT
>>>>> "Peter" == Peter M Goldstein <peter_m_goldstein@yahoo.com> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message