I think this begs the question of what DAS "configuration" is. I'm not sure all configuration is part of a component type since the latter always has a 1:1 relationship with its implementation. For example, I believe the DAS configuration specifies mappings to database tables. Are these mappings potentially sharable across different components? JPA has the "PersistenceUnit" concept to express this. A PersistenceUnit defines the set of entities that can be managed by a particular context but must always correspond to one database. For example, an application may have one or more PersistenceUnits (I would imagine in typical cases it is one but not always). Related to this, configuration may define which DataSource to use. In DAS, is it possible that multiple <implementation.das> entries want to use the same mapping and DataSource configuration?
If that is the case, you can probably do something similar to what Meeraj is doing with the JPA integration and have the configuration information parsed and cached as a special system service in the application composite. If so, we can drill down into more detail here.
If I understood your question correctly, DAS allows a 1:1 and 1:N relationship, An application could have multiple components using the same config file, or could split the config file based on the components model... but the choice is really made by the app developer. - Luciano On 11/14/06, Jim Marino <[EMAIL PROTECTED] > wrote:
On Nov 14, 2006, at 8:15 AM, Venkata Krishnan wrote: > Hi, > > I have tried my best to explain... just in case something is not > right in > this could somebody pitch in please. > > Thanks. > > - Venkat > > On 11/14/06, Luciano Resende < [EMAIL PROTECTED]> wrote: >> >> Hi All >> >> I have updated (Tuscany-904) with a new version of the DAS >> container. >> This is based on the initial contribution that Amita did, with some >> clean-up, refactoring and additions to try to fix a possible >> problem with >> mutable properties that are shared among instance (pointed by Jim >> Marino)... >> Currently, this is just the initial drop that I want to make >> available in >> the trunk so other can start to take a look and Amita and I could >> collaborate easier... unit testings, sample, etc are coming... I'd >> appreciate if anyone could help get this to the trunk if there is >> nothing >> wrong with this... >> >> Couple Questions: >> >> Could someone take a quick look at ComponentTypeLoader and see if >> it's >> looking Ok ? I was not sure about what this loadFromSideFile >> means ? what >> is >> the "side file"? Is this something particular to Script container ? > > > A sidefile is one way of exposing the configurable aspects of an > implementation. The other way is thro annotations. Yet another is to > follow some coding conventions so that this information is > introspectable. > The sidefile way of doing things is, to the best of what I > understand, a > common means across containers. i.e. you can have javascript, java, > ruby, > das (if you will) components all using the sidefile in a similar > manner as > this is prescribed by the specs. Yes component type is a common means but allows an implementation type (e.g. implementation.java, implementation.ruby) to extend the component type schema with specific metadata. Also, there is a 1:1 relationship between a component type and an component implementation. > For the introspectable way you will see > Java and JavaScript vary in how they achieve this. The same goes for > annotations - right now the java container alone can leverage this > (as far > as I know). > > Also, I wasn't sure what time is the appropriate time to load the > das config >> file when provided ? Right now is being loaded at >> DataAccessImplementationLoader, if you guys think this should go in a >> different place, please let me know... also would be good to know >> why :) > > I think this begs the question of what DAS "configuration" is. I'm not sure all configuration is part of a component type since the latter always has a 1:1 relationship with its implementation. For example, I believe the DAS configuration specifies mappings to database tables. Are these mappings potentially sharable across different components? JPA has the "PersistenceUnit" concept to express this. A PersistenceUnit defines the set of entities that can be managed by a particular context but must always correspond to one database. For example, an application may have one or more PersistenceUnits (I would imagine in typical cases it is one but not always). Related to this, configuration may define which DataSource to use. In DAS, is it possible that multiple <implementation.das> entries want to use the same mapping and DataSource configuration? If that is the case, you can probably do something similar to what Meeraj is doing with the JPA integration and have the configuration information parsed and cached as a special system service in the application composite. If so, we can drill down into more detail here. > The config file could very well be read / parsed during 'load' time > using > the loader. The loading is just about picking up the component > definition > information from the scdl file and creating a java object model for > them. > The next phase is the 'build' phase where you must create the > necessary > runtime artifacts making use of the model you have defined in the > loading > phase. In your case I would imagine that you would inject the > config values > into the DAS Engine during the build time. > One minor thing here. Unless the configuration values are always immutable, an ObjectFactory should be injected otherwise one component could accidentally modify a configuration parameter of another as instances will be shared. When the component implementation instance is created, the AtomicComponent will need to call all of the ObjectFactory.getInstance methods to retrieve configuration values that are injected. If the values are mutable, the ObjectFactory will need to instantiate, copy or clone a value. If the value is immutable, it can always pass the same one. In part of the refactors to container.script, I introduced some code that does this which can be used as an example. > Well, comments and feedback are welcome... Note that I'm still getting >> familiar with the Container SPI, so, please let me know if I >> misunderstood >> something on the implementation. > > > - Luciano Resende >> Apache Tuscany >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
