Peter M. Goldstein wrote:
Hey Folks,
I'm wondering what people on the list are thinking about the future
relationship between Avalon containers and JDBC DataSources.
I'm not doing anthing related specifically to JDBC DataSources but I am doing stuff related to containers and JNDI.
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.
Correct.
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.
In the case of Phoenix the context value will only contain the Phoenix specific context values. In the case of Merlin the context will contain quasi-standard context entries plus any context entries defined in the deployment profile for the component. In the Merlin case this means that your getting whatever you declare relative to a particular key - but you cannot provide supplimentary runtime information when invoking get (on Context) or lookup (on ServiceManager or CoponentManager)..
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.
Both Context and ServiceManager take a key as the criteria. The Context key is an Object so there is a lot of scope for packing this with extra information providing your running inside a container that is providing the context implementation and is capable of understanding a key that is somethying more sophisticated that a String (although the String parmeter on ServiceManager can still provide substantice content). If you were to assume that the string was a URN, that it seems to me that it should be ferasible for a container implementation (via context or via ServiceManager) to provide support for access to a JNDI name context.
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.
Today the "standard" context argument is a string basically returns something based on some published semantic. We don't have any standard string keys in Avalon at the moment (which is something I hope we will get back to in the not so distant future). Part of that discussion could encompass key interpritation - as this is something that needs to be addressed to synchronize differenent container semantics.
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.
Maybe I'm missing the key point here - but I tend to thik that container internals should be kept a long way away from components - i.e. what a container does to get what it needs is totally orthoginal to what a component needs to do to get what it needs. The sub-optimal aspect comes into the notion of sharing resoruces, however, the downside is container dependence because you are making implicit assumptions about the services available for a particular container.
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.
In the work on-going within the Merlin project that is an investigation into JNDI at two levels. Firstly, the question of deployment of a Merlin kernel based on a JDNI lookup (including how this can provide the API user access to a service directory). Secondly, the question of JNDI resource inclusion into context is on the drawing board - and this mainly concerns the question of (a) enabling JNDI resources to be declared as effective component dependencies (b) mechanisms supporting the dynamic addition of services into a naming context, and (c) access to those services.
All of the above is very early stage so don't expect anything real fast - but it is being working on!
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
