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]
