> -----Original Message-----
> From: Samuel Ferrer [mailto:[EMAIL PROTECTED]
> Sent: 24 November 2004 14:03
> To: [EMAIL PROTECTED]
> Subject: RE: context
>
>
> Hi quijote
>
> I am new to this project too, but I have been following the
development of
> metro quite close.
>
> I think, and guys correct me if I am wrong, the context is the
container
> in which a component is running.
Yep - that's right.
> The context gives you access to the
> container ...if I am right, then dont reduce it to the norrow concept
> of context in EJB, because metro is just trying to avoid the situation
> of deployment specifics scenario, which is what you get when working
> with RJBs ... EJB has a long way to go toward "independency of
concern",
> although they are getting close.
IMO there are two separate view points related content - and a technical
aspect that is worth noting.
The two viewpoints:
a) standard context entries - in particular things like the
component name, working and temp directory, classloader,
partition name, etc. - standard entries are convenient because
you don’t need to think about runtime directives (i.e. statements
to a container telling it what to do) - but convenience to some
extent ties you to a one or at least a small number of specific
component model (e.g. Avalon, Metro, etc.)
b) independent context entries - this is what you declare on your
component that you something specific - e.g. a timestamp object or
perhaps a keystore. In this scenario you (component developer)
define the key, and I (deployment manager) define the strategy to
be used to fulfill the requirement. In this scenario the
deployment
strategy can be packaged along with the component (as part of a
composite component definition) which enables a hell of a lot of
freedom in terms of packaging and zero api lock-in.
The technical aspect concerns the distinction between content
information and service dependencies. If we look at something like a
timestamp context value - of the type java.util.Date - and we compare
this with a service such as org.wonderland.Widget. In the case of the
widget there is an entire management process behind the scenes that is
responsible for the orderly establishment of a widget provider ahead of
any widget consumers. In contract you typically find non-managed object
in Context - e.g. java.util.Data, java.lang.String,
java.lang.ClassLoader - or other objects constructed outside of a formal
component viewpoint.
>From the container author point-of-view the separation is important, but
for the component developer I'm of the impression that the two
abstractions should potentially merge (but with an emphasis on
comprehensive model for the declaration of solutions as either part of a
composite component or as custom deployment scenarios) - but this is
more a question of direction than current practice.
> I have been looking around in dpml site
> (http://www.dpml.net/central/products/metro/system/index.html) and I
found
> no definition for "context".. only the one you see on that link (is
that
> guys what you meant by context?)
:-)
The guys are running as fast as they can! Immediate priorities are
focused on the Transit product (resource management layer) and getting
this finalized (Transit is basically the next generation
cache/repository management solution reengineering to be a generic
high-value product capable of supporting both Metro and Magic with zero
API dependency). Once Transit completes the qa process we will move our
attention towards a release of new improved Magic (which actually runs
as a Transit plugin) following which the flagship product Metro will
take center stage. At this point much of the documentation concerning
component api, deployment strategies and runtime semantics will receive
a lot of attention. If you or anyone else want to be a part of that -
then please signup on dpml dev and support lists and tell us what your
priorities are.
> So, I am just daring, so a definition comes out of an reaction.
Nope - the definition comes from the documentation presenting the
complete semantic and computation model - but what sucks is that there
are not enough hours in the day to get everything done ASAP. But
practically speaking - right now the real docs on context are largely
related to the information presented under the context directives:
http://www.dpml.net/central/products/metro/composition/directives/contai
ner/component/context/index.html
Cheers, Steve.
> Saludos
> maquina
>
> >From: "El Quijote" <[EMAIL PROTECTED]>
> >Reply-To: "Avalon framework users" <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: context
> >Date: Wed, 24 Nov 2004 10:30:26 +0000
> >
> >Hi!
> >I'm new to the subject of the avalon-framework and find the
expression
> >"context for a component" very abstract. Could somebody explain to me
> what
> >is meant?
> >
> >Many Greetings...
> >
> >_________________________________________________________________
> >Die rote Karte für lästige E-Mails. MSN Hotmail mit Junk-Mail-Filter.
> >http://www.msn.de/antispam/prevention/junkmailfilter Jetzt kostenlos
> >anmelden!
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today it's
FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
