Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>
>>Berin Loritsch wrote:
>>
>>
<snip>
>>I've been digging through the lfecyle extension stuff. There
>>is no class level association between a lifecycle interface
>>and its manager which means that reflection will not solve
>>the problem.
>>
>>
>
>Not as of yet. As I mentioned in another email, reflection also
>has several issues regarding the addition of more than one
>extension class.
>
>
>
>>The container cannot check the interfaces supported by a the
>>component class for an extension interface (because
>>Exploitable does not extends a base interface). What is
>>needed at the type (meta-info) level is a declaration of the
>>manager class.
>>
>>
>
>True. However, what happens if there are multiple extension
>handlers that can work with the interface?
>
>
Still thinking about this.
>If the LifecycelExtensionHandler class were to expose the
>interfaces that it handles, we can use reflection--as long as
>we can resolve the first problem from my above response.
>
>
>
>
>>A type implementing Exploitable introduces obligations towards it
>>container at two level - (a) that fact that it needs to be
>>handled by an
>>extension manager (e.g. LifecycleHelper), and (b) that it has context
>>dependecies (i.e. the container has to populate the context
>>entries with
>>values. Both of these characteristics are meta-info level stuff.
>>
>>At the type (meta-info) level we would be looking at something like:
>>
>><component-info>
>> <component>
>> <name="my-exploitable-component"/>
>> </component>
>> <extensions>
>> <!-- order list of extensions -->
>> <extension class="ExploitationManager" name="exploitable">
>> <context>
>> <!-- context constraints here -->
>> </context>
>> </extensions>
>> </extensions>
>></component-info>
>>
>>
>
>That would probably work. The important thing is that we provide
>a means of *validating* if we can use the component in our system.
>As long as we don't force one LifecycleHelper implementation, we
>can do this much.
>
>
Just so we are on the same page - the above <component-info/> references
an explicit class (i.e. an extension manager implementation class). If
we change this to an interface then we should consider attribites within
the extension declaration that can be used to quality a implementation
selection. I.e. the above defintion would look like:
<component-info>
<component>
<name="my-exploitable-component"/>
</component>
<extensions>
<!-- order list of extensions -->
<extension type="ExploitationManager" name="exploitable">
<attributes>
<!-- selection criteria attributes go here -->
</attributes>
<context>
<!-- context constraints here -->
</context>
</extensions>
</extensions>
</component-info>
>
>
>>Remember that the information is developer defined and cannot be
>>modified by a configuration.
>>
>>
>
>Absolutely.
>
>
>
>
>>Next is the Profile (meta-data) where we are concerned with
>>customization of the instantiation criteria. In the case of an
>>extension, we are concerned with declaring the context
>>information to be supplied to the context instance used in
>>lifecycle handling implied by the extension.
>>
>>
>
>Wouldn't we want to just merge all the context requirements into
>one section. It would be easier to deal with than having to
>modify it in several locations.
>
>
The only reason I added this was if a extension manager declares a
requrement for a context entry that was in addition to the genral
component type context dependecies. Thinking about this some more, it
may be reasonable that the context criteria at the meta level of an
extensions and the conext directives at the meta-data be dropped (it
would simply things).
>
>
>>>I really haven't found a need beyond these four basic types of
>>>lifestyles. Have you run across something that I haven't?
>>>
>>>
>>>
>>Before answering that I want to dig a little bit more.
>>In Fortress there are the handler dealing with the following
>>lifestyles:
>>
>> singleton - (always returns the same instance)
>> factory - (creates a new instance)
>> thread - (provides new instance keyed by thread)
>> pooled - (returns recyclable instances per request)
>>
>>All of the above are constraints supplied by a developer
>>relative to the type of component. As such, this is meta-info
>>and should appear via the Type class. At the Profile level
>>there is information concerning things like pool size - etc.
>>(i.e. the deployment criteria). At the type level I'm
>>currently thinking about how lifestyle could be represented using
>>component type attributes. I'm assuming the following would
>>be sufficient:
>>
>> <component-info>
>> <component>
>> <attributes>
>> <attribute key="avalon:lifestyle" value="pooled"/>
>> <attributes>
>> </attributes>
>> </component-info>
>>
>>Where the "avalon:lifestyle" attribute value could be one of pooled,
>>thread, singleton or factory.
>>
>>
>
>Would these be attributes that are consistent with all containers?
>If so, I would prefer something along the lines of:
>
><component-info lifestyle="pooled"/>
>
>It is a core concern of how the container deals with the component,
>and it is *far* less verbose.
>
But inconsitent with the meta-info model as it is currently defined.
The attributes structure is already in place and is the same across
both excalibur.meta and excalibur.containerkit. Yes - its more verbose
but I would suggest we stick with the attribute approach for now and
maybe come back to this later oce we have something in place.
>
>The more verbose attributes section should IMO be reserved for
>additional component guarantees like persistent vs. transient storage.
>
>
>
>>In a component profile we need to be able to provide
>>lifestyle parameters:
>>
>> <component class="MyExploitableComponent">
>>
>> <!-- declaration of context entries to be supplied a handler -->
>>
>> <lifestyle class="MyPoolManagerImpl">
>> <entry key="initial" class="int">14</entry>
>> <entry key="maximum" class="int">100</entry>
>> </lifestyle>
>>
>> </component>
>>
>>
>
>
>Hmm. Currently, this is handled by attributes on the config.xml:
>
><my-pooled-component pool-max="100" pool-min="14" pool-grow="4"/>
>
>Those attributes allow the person who is responsible for *tuning*
>the application quick access to the necessary information. I am
>not sure how the "MyPoolManagerImpl" is expected to behave. MPool
>has its own Command that operates every so often that sets the pool
>size. Eventually I want to give that Command some real brains
>so that it can pre-allocate instances before the expected load, and
>de-allocate instances during times of expected quiet.
>
>The bottom line is that I want MPool to get to the point where it
>tunes itself, and the whole constraint of initial and maximum number
>of instances is no longer necessary.
>
>
At the profile level we are descriubing the information that the
container needs to instantiate an instance of a component type. The
addition of a <lifestyle/> element to the <component/> defintion means
that we are adding a new class to the merlin.model package. The new
class will expose an API that rovides access to the neccessary
information to properly setup a lifestyle handler. The first issue to
be deal with with defintining the APIs for the different meta-data
objects that qualify the lifestyle management, secondly, we would need
to update the fortress handlers to take this mata-data as the
construction criteria.
>
>
>
>>During validation, the container would have to check that the
>>component lifestyle attribute in the meta-info model is
>>consitent with the class supplied in the meta-data model. In
>>addition, for a clean defintion of this at meta-info and
>>meta-data levels, we would need to get somewhat
>>more rigorouse about the lifestyle meta-data context entries
>>than what I have described above (but you get the idea).
>>
>>
>
>Ok.
>
>
>
>>>:) Yep, you got it!
>>>
>>>
>>>
>>>
>>Do I get a prize?
>>;-)
>>
>>
>
>
>Sorry, we ran out :(
>
>
>
Zutt!
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
