Hey Folks, I'm wondering what people on the list are thinking about the future relationship between Avalon containers and JDBC DataSources. Let me lay out the status quo as I see it and some of the issues that I see, and any of you can feel free to comment/correct. Almost all of my experience is with Phoenix, so I'm going to be approaching things from that perspective.
As I understand it, the container currently doesn't bear any responsibility for initializing DataSources or providing DataSources to components hosted in the container. This means that if components running inside a container need access to a DataSource they must both configure and initialize it themselves or obtain the DataSource from another component. Moreover, even if the container initialized and exposed DataSources, the current Context lookup method leaves the details of how the DataSource would be retrieved up in the air. It's not clear to me what other method an Avalon component would use to look up a JDBC DataSource (ServiceManager?). I know there was some discussion on modifying this lookup method, but I'm not sure it came to a consensus. Right now, if a set of components want to use JDBC functionality, the standard way to do this appears to be some variation of the following. A component is defined that is responsible for configuring, initializing, and exposing JDBC DataSources (i.e. DefaultDataSourceSelector). Other components that require DataSources declare a dependency on that component. The component that exposes the DataSources does so through an arbitrary interface that isn't standardized. It could be a DataSourceSelector, it could just as easily be something else. Finally, I don't know much about the situation where the Avalon container is embedded inside another container that exposes DataSources to its hosted applications (i.e. Phoenix inside JBoss, Merlin inside Tomcat), but I don't believe those DataSources are made available to Avalon components. Can someone clarify this for me? Thanks. If they can't be made available, then I would add this as another issue on the list below. Now, assuming the above is correct, I see a couple of issues. First, there is no standard way for a component to access a DataSource. There is an implicit binding to another component in the system. So if I write a component for one application, and want to reuse it in another, I need to ensure that the same method is being used by the second application to expose DataSources. This is a coding and not a configuration level issue. Most other types of containers have made this a configuration level issue using JNDI. Second, in this set up one generally has to ensure that the component supplying the database connections is at the base of the dependency tree. In most systems, data stores are fundamental. So if a database is being used, it's important that they be available early. This isn't a huge deal, but it simply adds an extra layer to the dependency declarations. Third, the problems with the ill-defined Context lookup impact this question. If the Context is to be used to lookup data sources, it's not clear how to do that in a standard way. Fourth, I would imagine there would be situations where the container may want access to data sources for its own purposes (i.e. logging). In the current setup container-configured data sources and component-configured data sources must be distinct. This seems sub-optimal. Do people have any thoughts on all of this? I'd be curious to see what direction Avalon developers have in mind. Also, this discussion is closely related to the issue of how Avalon and JNDI should coexist, so I'd also be interested to hear what folks think about that. --Peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
