You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/07/09 21:13:47 UTC
[RT] The Ominous Context
The Context object (Contexualizable) is one of those things that is necessarily
very flexible. It means different things in different systems. As long as it
is used consistently, everything is fine. It is when there is inconsistency in
a system that we have problems.
There have been many concepts and ideas tossed around, but we need to unify
them. In this case that means we need to start talking the same language and
working with the same concerns. We should leave the container aspect wide
open for implementation details, but the user (i.e. the component writer)
is the primary concern for this discussion.
For that reason, I would like us to focus on how the *user* identifies context
entries and how the *user* accesses them. The container can do what it wants
to as long as the user does not have to adapt for different containers.
Right now, Fortress and Phoenix share a couple common entries but that really
isn't enough. I believe Stephen is on the right track in allowing the meta
information to allow a container to validate that it can use a component. That
is a good thing.
To that end, we would need a set of validation AMTAGS for the context entries.
Looking at the problem from a 1000 foot view, we find that there are many
different uses and ways of using the context. Each have their merrits, but we
run into the problem of trying to identify what is the set of common context
entries. Attempts in the past have stirred up the glass house and bike shed
syndrome, and worse such contracts are not truly enforcable by code and subject
to change over time.
I have a very radical solution for identifying common context entries. Don't.
How can we have interroperable context entries then? I'm glad you asked, so
here is the answer:
-oO Context Declaration and Definition 0o-
The user of a system has two separate concerns they have to worry about. The
first concern has to do with declaration, much like we declare any required
services that we need for our component. In fact, I propose we follow the same
model that we have for services as we do for context entries. That model is
that the component declares its requirements, and in assembly we identify how
those requirements are fulfilled. That's right, the second concern which is
defining the context entries and values belongs to application assembly.
This solution provides the maximum amount of flexibility for the application
developer, while ensuring that the system can perform its validations and share
information accross several components.
-oO Context Use Cases Oo-
Contexts are used in a variety of different manners. For example, one common
use is to share global configuration information like the application context
directory and the temp directory that a component can use. Even then there are
discrepencies as to how that resource should be presented. In a Servlet
environment you don't really want a "file" URL for the context directory as that
is not portable, but in most cases it works quite well.
Contexts can also be used to supply runtime meta data to the component such
as its "name", or some other info that might be accessible via the
ServletContext object. Not to mention, some context information might be
request specific, adjusted by Accessors and such.
All that says that we cannot assume that we can ensure that common names are
expected to have static information. Some of that information may very well
be dynamic. How do we enable dynamic context entries (like a session object)?
It can be done, and we really have the technology to make that happen.
-oO Declaring our Context Requirements Oo-
In the spirit of the AMTAGS proposal, we need to simply declare our need,
and not the implementation. For this reason, I would like to outline something
like this:
/**
* @avalon.context ref="urn:component:name"
* @avalon.context key="classloader" ref="urn:avalon:classloader"
* @avalon.context key="app.home" ref="urn:avalon:app/home" type="URL"
* @avalon.context key="session" ref="urn:my-app:seccion" mutable="true"
*/
public void contextualize( Context context )
{
// ...
}
The @avalon.context is the new AMTAGS name. The attributes' significance
is outlined below:
Attribute Description
--------- -----------
key The lookup value, defaults to the "ref" entry.
ref The URN reference in the assembly file.
type The type that the component expects the value to be in,
defaults to the ref definition.
mutable True or false value letting the container know that the
component checks the value every time it is used--expecting
it to change. Defaults to false.
That way we can enforce a common definition for all of these entries,
or how to reference them from extensions. The lifecycle extensions
or container extensions should be able to add and change values for
the URN namespace that belongs to it. That means we can choose a
set of context values for a namespace and work on that.
The core set of URNs would be under the namespace of "urn:avalon:",
which would be easy enough to define if we know that a container
extension might define another set of entries. For example I might
have an application specific extension that populated values for
"urn:my-app:". As long as that extension is in place, all is well.
Global context information would be set in the assembly file, which
includes things like the "urn:avalon:" namespace. Also, by identifying
the namespace that an extension is allowed to play with, we can easily
put in security checks to ensure that the extension is well behaved.
Attempts for MyAppExtension to change values in "urn:avalon:" namespace
context values would allow the container to notify the administrator
of a potential rogue extension.
It also allows us to set up an API where the context entries are set
by URN and automatically converted to the lookup name (if it has changed).
All in all, I think we will have a win/win situation.
As to the initial set of "urn:avalon:" namespace entries, let's leave
that empty for the time being, and add to it as we have need. The
"urn:avalon:" namespace would be reserved for truly global information,
leaving component or partition specific information to the "urn:component:"
and "urn:partition:" namespaces respectively.
How does this sound?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] The Ominous Context
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Niclas Hedhman wrote, On 14/07/2003 9.42:
>
>> Stephen wrote:
>>
>>> I hate this subject because I keep changing my mind!
>>
>>
>>
>> Isn't that a good thing?
>
>
> :-))
>
>> <snip reason="agree" />
>
>
> I still don't get the example you write, Stephen: "Context represents
> an import stage during which a container can gather non-component
> artifacts and apply them to a component before servicing occurs. A
> context entry could be something like a KeyStore which can be used by
> a component during the servicing stage (as an example)".
>
> Could you please explain a bit more in detail?
Sure - as thing stand we have a phased lifecycle [deployment
[instantiation],
[logging],[contextualization],[servicing],[configuration],[parameterization],
[create-extension,...],[initialization],[start]], and the corresponding
decommissioning phases.
During deployment there are a number of points during which context
information is exposed:
1. during the contextualization phase
2. during the create-extension[n] handling
3. during the access-extension handling
4. during the release-extension handling
5. during the destroy-extension handling
The context gathering stage inside a container can occur as soon as you
bring together the meta-info and meta-data. Your not concerned with
dependencies or assembly semantics - your just concerned with mapping
and/or constructing context entries. The more information you push into
context entry dependency declarations (and corresponding context entry
directive) the small your code gets because your basically telling the
container to take care of the problem for you. In addition, you
lifecycle extensions can get a lot smarter because they have more
information available to them. This means more deduction in component
implementation responsibility - a.k.a improved S.O.C.
Here is a more concrete example (cut-and-paste from the composition
package). First of all the type information which is where the
component is declaring if computation dependencies:
<type>
<info>
<name>component-a</name>
<lifestyle>singleton</lifestyle>
</info>
<context>
<entry key="urn:avalon:partition.name"/>
<entry key="urn:avalon:classloader"/>
<entry key="urn:avalon:home.dir"/>
<entry key="urn:avalon:temp.dir"/>
<entry key="urn:avalon:name" alias="name"/>
<entry key="home" type="java.io.File"/>
<entry key="time" type="java.util.Date" volatile="true"/>
</context>
<services>
<service type="org.apache.avalon.composition.model.testa.A"/>
</services>
</type>
If we look at the last context entry "time" - this is basically a
statement by the component that it needs a time value. This could
serving a secure time-stamp or whatever (you could add attributes under
the entry to qualify the criteria). On the other side of the equation
(moving from meta-info to meta-data) we see some directives that tell
the container how to construct the Date value:
<container>
<component name="test-a"
class="org.apache.avalon.composition.model.testa.TestA">
<context>
<entry key="home">
<constructor class="java.io.File">
<param class="java.io.File">${urn:avalon:home.dir}</param>
<param>xxx</param>
</constructor>
</entry>
<entry key="time">
<constructor class="java.util.Date"/>
</entry>
</context>
</component>
</container>
This is the real cheap-and-nasty Date instance creation - simply
instanting a new instance of java.util.Date. What is important to note
is that this could be a full blown secure time-server provide the Date
instance. The actual decision is presented under the container side of
the system.
An important aspect here is the management of individual entries
(context or service). The meta-data (directives) basically break down
into a object model (which is where JMX management comes in). For any
given entry (service or context) we can:
1. differentiate between context and service (inside
the container) - which means I still get the early
harvesting of information that I want
2. while abstracting this difference out from the
component implementation and runtime viewpoints
Now I bet that made things really clear ;-)
Cheers, Steve.
>
> TIA
>
> ...
>
>> From my perspective (being, or trying to be, mainly a component
>> author) it
>> is fairly irrelevant whether it is in the Contextualizable or
>> Serviceable
>> contract, as long as;
>>
>> 1. It is a single lookup.
>> 2. If the container doesn't provide it by default, I can provide an
>> implementation.
>>
>> And your suggestions above seems to fulfill this very well, the rest is
>> implementation details ;o).
>
>
> I tend to agree.
>
> Do the ones that *use* containers need to implement the Context and
> cannot use a Service instead? Because this is the main point IMHO.
As a delivery mechanism I don't need both interfaces.
As a declaration mechanism (meta-data) I need both the notions of
context and service (or in other terms - atomic objects verus assembled
objects).
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] The Ominous Context
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Niclas Hedhman wrote, On 14/07/2003 9.42:
> Stephen wrote:
>
>>I hate this subject because I keep changing my mind!
>
>
> Isn't that a good thing?
:-))
> <snip reason="agree" />
I still don't get the example you write, Stephen: "Context represents an
import stage during which a container can gather non-component artifacts
and apply them to a component before servicing occurs. A context entry
could be something like a KeyStore which can be used by a component
during the servicing stage (as an example)".
Could you please explain a bit more in detail?
TIA
...
> From my perspective (being, or trying to be, mainly a component author) it
> is fairly irrelevant whether it is in the Contextualizable or Serviceable
> contract, as long as;
>
> 1. It is a single lookup.
> 2. If the container doesn't provide it by default, I can provide an
> implementation.
>
> And your suggestions above seems to fulfill this very well, the rest is
> implementation details ;o).
I tend to agree.
Do the ones that *use* containers need to implement the Context and
cannot use a Service instead? Because this is the main point IMHO.
If users need only to make Services and make the container handle them,
there is no need to give them this ability of adding things to a
Context, as they can be done as a Service.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] The Ominous Context
Posted by Niclas Hedhman <ni...@hedhman.org>.
Stephen wrote:
> I hate this subject because I keep changing my mind!
Isn't that a good thing?
<snip reason="agree" />
> If you make the assumption that any entry *must* fall into one of the
> following three categories, then I think its possible:
>
> 1. a standard context entry
> 2. a registered service type
> 3. a custom context type (i.e. declared in meta-data)
>
> Umm, interesting thing is that this would only require one small
> addition to the meta-info model, namely the addition of the version
> attribute on a context entry. Legacy A4 support could be provided by
> provided my mapping the generic context as the provider to both
> serviceable and contextualizable.
>From my perspective (being, or trying to be, mainly a component author) it
is fairly irrelevant whether it is in the Contextualizable or Serviceable
contract, as long as;
1. It is a single lookup.
2. If the container doesn't provide it by default, I can provide an
implementation.
And your suggestions above seems to fulfill this very well, the rest is
implementation details ;o).
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] The Ominous Context
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>>Only if your context entry has a null construcor. How are you going to
>>diferrentiate between the establishment of a service and the creation of
>> a File instance? If context were removed, we would be forced to declare
>> factories for any "non-component" and that's not an attractive
>>proposition.
>>
>>
>
>Well, from the User Components point of view, it is completely irrelevant
>of "How" the entry ended up in the ServiceManager's lookup, the container
>could very well have a set of hardcoded entries, just like the hardcoded
>entries in the Context today. But then I don't get the dependency checks I
>am after. I probably would like to see that the entries being exposed for
>dependency resoloution at assembly.
>
>By moving the Context entries to the ServiceManager, then if a particular
>container didn't expose a required value, one could adopt a it to support
>the missing entries that components are looking for, by assembly
>declarations.
>
I hate this subject because I keep changing my mind!
OK - so I thought about this some more and I agree with what your saying
in that "entries" (context or service) could be presented to a component
using a single interface (Contextualizable, Serviceable, or something
similar). Let's assuming we use contextualizable for the moment - the
impact would be that instead of declaring <context/> + <services/> we
could declare something like:
<type>
<info>
<name>DemoType</name>
</info>
<context>
<entry key="urn:avalon:name" alias="name"/>
<entry key="urn:avalon:partition.name"/>
<entry key="keystore" type="java.security.KeyStore"/>
<entry key="authority" type="org.omg.pki.RegistrationAuthority"
version="2.1"/>
<entry key="time" type="java.util.Data" volatile="true"/>
</context>
</type>
So far so good. The component author is not concerned with "how" an
entry is established and all of the entries are simply statements of
dependencies that the component type has.
When a container looks at the above list is will resolve the
"urn:avalon:*" entries using its internal standard entry set. That
leaves us with keystore, authority and time. For each of these, the
container knows if a service (a.k.a component) is available to handle
the type. In which case the container is probably going to recognize
the RA as a registered service, leaving "keystore" and "time" as custom
context entries that need to be constructed (i.e. the container has to
pull in some meta-data and process some directives).
If you make the assumption that any entry *must* fall into one of the
following three categories, then I think its possible:
1. a standard context entry
2. a registered service type
3. a custom context type (i.e. declared in meta-data)
Umm, interesting thing is that this would only require one small
addition to the meta-info model, namely the addition of the version
attribute on a context entry. Legacy A4 support could be provided by
provided my mapping the generic context as the provider to both
serviceable and contextualizable.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] The Ominous Context
Posted by Niclas Hedhman <ni...@hedhman.org>.
> Only if your context entry has a null construcor. How are you going to
> diferrentiate between the establishment of a service and the creation of
> a File instance? If context were removed, we would be forced to declare
> factories for any "non-component" and that's not an attractive
> proposition.
Well, from the User Components point of view, it is completely irrelevant
of "How" the entry ended up in the ServiceManager's lookup, the container
could very well have a set of hardcoded entries, just like the hardcoded
entries in the Context today. But then I don't get the dependency checks I
am after. I probably would like to see that the entries being exposed for
dependency resoloution at assembly.
By moving the Context entries to the ServiceManager, then if a particular
container didn't expose a required value, one could adopt a it to support
the missing entries that components are looking for, by assembly
declarations.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] The Ominous Context
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>>Niclas Hedhman wrote:
>>
>>
>>>Looking from 10,000 feet, what is then the difference between an
>>>"object" residing in Context and one that can be looked up in the
>>>ServiceManager??
>>>
>>>
>>Currently, it is the purpose of the object. I understand where you are
>>coming from. For Avalon 5 whenever we get to that, I would like to have
>>one lookup manager--perhaps even a JNDI context that is passed in (no
>>InitialContext capabilities)--but that is the future. We have the
>>present Avalon 4 to support.
>>
>>
>
>IMVHO it is a bad habit to expand on or extend a concept that is
>planned/considered to be removed.
>
I would say that it is the subject of discussion. I would not say that
Context is planned/considered for removal. Context represents an import
stage during which a container can gather non-component artifacts and
apply them to a component before servicing occurs. A context entry
could be something like a KeyStore which can be used by a component
during the servicing stage (as an example).
What is *really* needed is tigher semantics on context entry requests.
>
>I would like to propose that the Context package is deprecated, and the
>context values are made available via the ServiceManager instead. That
>would also give the Component authors some reasonable time to adjust to
>the complete removal later.
>
>Aaron Farr wrote;
>
>
>>The difference is lifecycle and lifestyle management.
>>
>>
>
>
>
>>Objects from the ServiceManager are guaranteed to go
>>through the proper lifecycle and have proper lifestyle
>>management. You have no such promise for Context values.
>>
>>
>
>Are you saying is that "because Context values doesn't have a defined
>lifecycle, we must keep them"? Context values can be created as components
>but not the other way around, so...?
>
>If I don't declare any interfaces in the component, it could be a Context
>value, i.e. ContextValue is-kind-of Component, and I could basically
>create Components that behaves like the existing context values.
>
Only if your context entry has a null construcor. How are you going to
diferrentiate between the establishment of a service and the creation of
a File instance? If context were removed, we would be forced to declare
factories for any "non-component" and that's not an attractive proposition.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] The Ominous Context
Posted by Niclas Hedhman <ni...@hedhman.org>.
> Niclas Hedhman wrote:
>> Looking from 10,000 feet, what is then the difference between an
>> "object" residing in Context and one that can be looked up in the
>> ServiceManager??
>
> Currently, it is the purpose of the object. I understand where you are
> coming from. For Avalon 5 whenever we get to that, I would like to have
> one lookup manager--perhaps even a JNDI context that is passed in (no
> InitialContext capabilities)--but that is the future. We have the
> present Avalon 4 to support.
IMVHO it is a bad habit to expand on or extend a concept that is
planned/considered to be removed.
I would like to propose that the Context package is deprecated, and the
context values are made available via the ServiceManager instead. That
would also give the Component authors some reasonable time to adjust to
the complete removal later.
Aaron Farr wrote;
> The difference is lifecycle and lifestyle management.
> Objects from the ServiceManager are guaranteed to go
> through the proper lifecycle and have proper lifestyle
> management. You have no such promise for Context values.
Are you saying is that "because Context values doesn't have a defined
lifecycle, we must keep them"? Context values can be created as components
but not the other way around, so...?
If I don't declare any interfaces in the component, it could be a Context
value, i.e. ContextValue is-kind-of Component, and I could basically
create Components that behaves like the existing context values.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] The Ominous Context
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
>
>> -oO Context Declaration and Definition 0o-
>>
>>The user of a system has two separate concerns they have to worry about.
>> The first concern has to do with declaration, much like we declare any
>>required services that we need for our component. In fact, I propose we
>>follow the same model that we have for services as we do for context
>>entries. That model is that the component declares its requirements,
>>and in assembly we identify how those requirements are fulfilled.
>>That's right, the second concern which is defining the context entries
>>and values belongs to application assembly.
>>
>>This solution provides the maximum amount of flexibility for the
>>application developer, while ensuring that the system can perform its
>>validations and share information accross several components.
>
>
> Looking from 10,000 feet, what is then the difference between an "object"
> residing in Context and one that can be looked up in the ServiceManager??
Currently, it is the purpose of the object. I understand where you are coming
from. For Avalon 5 whenever we get to that, I would like to have one lookup
manager--perhaps even a JNDI context that is passed in (no InitialContext
capabilities)--but that is the future. We have the present Avalon 4 to
support.
Purpose of ServiceManager: to obtain a reference to other components (AKA
services).
Purpose of a Context: to obtain a reference to global information (e.g.
Files, URLs, etc.)
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] The Ominous Context
Posted by J Aaron Farr <ja...@yahoo.com>.
On Thu, 2003-07-10 at 06:21, Nicola Ken Barozzi wrote:
> Niclas Hedhman wrote, On 10/07/2003 5.43:
>
> ...
> > Looking from 10,000 feet, what is then the difference between an "object"
> > residing in Context and one that can be looked up in the ServiceManager??
The difference is lifecycle and lifestyle management.
Objects from the ServiceManager are guaranteed to go through the proper
lifecycle and have proper lifestyle management. You have no such
promise for Context values.
>
> In reality, if I have well understood, the Context in Avalon means
> ContainerServices. They are all the services that are exposed by the
> container itself and not the Components it assembles.
>
> But Fortress exposes some of its services as Components IIUC... so do we
> really need a Context?
Taking in Berin's comments as well, I think we find that for Avalon5 we
perhaps do NOT need a Context as long as we have a sufficiently
intelligent lookup scheme. For Avalon4, we've got one regardless.
Just to make sure I'm following:
Context key dependencies would be declared at the component/service
meta-info level (via AMTAGS or .xinfo, .xservice files). These would
use the urn scheme described by Berin.
Context key values with "urn:avalon" would be declared at the
container/kernel level (ie kernel.xml in merlin). These would be
handled by the container itself in some way (perhaps via extensions).
Context key values with "urn:my-app" would be declared at the block
level and handled by some block level context extension.
Does that seem correct?
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] The Ominous Context
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Niclas Hedhman wrote, On 10/07/2003 5.43:
...
> Looking from 10,000 feet, what is then the difference between an "object"
> residing in Context and one that can be looked up in the ServiceManager??
Wow, concise and 2thePoint :-)
IMHO this is the reason why the Context sufferes from the actual
problems. It has a contract (that nobody really agree on which it is)
that is not enforced by Java language emantics, *nor* Avalon framework
ones. There is no way whatsoever in which the developer sees that the
Context is used inappropriately.
Overmore, the term "Context" is used in many ways: BeanContext,
ServletContext, InvocationContext (or whatever it was).
Some "Contexts" pertain to the container, some to the request...
In reality, if I have well understood, the Context in Avalon means
ContainerServices. They are all the services that are exposed by the
container itself and not the Components it assembles.
But Fortress exposes some of its services as Components IIUC... so do we
really need a Context?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] The Ominous Context
Posted by Niclas Hedhman <ni...@hedhman.org>.
> Looking at the problem from a 1000 foot view
> I have a very radical solution for identifying common context entries.
> Don't.
So far so good.
> -oO Context Declaration and Definition 0o-
>
> The user of a system has two separate concerns they have to worry about.
> The first concern has to do with declaration, much like we declare any
> required services that we need for our component. In fact, I propose we
> follow the same model that we have for services as we do for context
> entries. That model is that the component declares its requirements,
> and in assembly we identify how those requirements are fulfilled.
> That's right, the second concern which is defining the context entries
> and values belongs to application assembly.
>
> This solution provides the maximum amount of flexibility for the
> application developer, while ensuring that the system can perform its
> validations and share information accross several components.
Looking from 10,000 feet, what is then the difference between an "object"
residing in Context and one that can be looked up in the ServiceManager??
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] The Ominous Context
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Berin and All!
<intro>
Trying to catch up with list, got a new job.
Still 62 msgs. pending :-)
</intro>
<main>
Am I following you, Berin?
BL> Contexts can also be used to supply runtime meta data to the component such
BL> as its "name", or some other info that might be accessible via the
BL> ServletContext object.
it is the responsibility of the component
itself to know that a certain context entry
is mutable and hence always look it
up, not lookup once and cache
BL> Not to mention, some context information might be
BL> request specific, adjusted by Accessors and such.
in implementation-land this means the Context
implementation will be backed by ThreadLocal(s)
</main>
<conclusion>
BL> How does this sound?
Sounds swell :-)
</conclusion>
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org