Hi Berin,
Thanks for your feedback.
On Thu, Jun 13, 2002 at 10:31:01AM -0400, Berin Loritsch wrote:
>
> The crux is you need to extend the lifecycle. Just out of
> curiosity in what ways do you need to extend the lifecycle?
> The fact that you can do it does not negate the fact that you
> are tying yourself to a certain container.
What I wanted to do was extend support for IoC so that it could be
applied in other domains, not just inside avalons framework.
This would allow developers using Avalon to leverage off of the same
pattern methodolody in specific application domains.
For example, Cocoon extends ECM to provide a new marker interface,
RequestLifecycleComponent which is how sitemap components get a
source resolver and the objectModel.
Leif extended ECM to add support for the Instrumentable marker,
which needs to be tested for within the current standard markers.
Unfortunately with the current classes Instrumentable can't be used
in Cocoon without merging Cocoon's CM hierarchy with it.
In our project, selection of which database pool to use is a little
more complicated that getting a DataSourceSelector, so I'd like to
have a Queryable marker interface or something similar which can
provide our components with the right connection object
automatically selected from the right pool each particular user should
access.
I guess all operations are adding functionality to components in
particular domains.
> The core problem is the contract between a component and a container.
> Currently, any Avalon Component should be able to function in any
> compatible container. The problem with extending the lifecycle is
> that you introduce new contracts that are not required to be enforced
> by other containers.
>
> Playing devil's advocate, what happens if someone royally screws over
> your favored container? Or what happens if the container you are using
> falls out of favor? You have to alter another container--or create your
> own.
Yes, I agree. People using custom markers would only be able to use
containers that have support for them. Hopefully though, the code
will be portable enough to be used in many containers.
We already have this problem now though. Cocoon sitemap components
won't work in any anything except for CocoonComponentManager,
which is based on ECM (already out of flavour). Instrumentable doesn't
work unless the CM has support for it. I'm hoping that generic
ComponentMarker code can alleviate this by being used ubiquitously.
> The only way to effectively enforce your contracts on lifecycle is
> to create your own container and maintain it. Fortress was designed
> with hierarchical containers in mind. In order to provide fast and
> easy customization on a component's lifecycle we need to be able to
> plug in our own ComponentFactory that manages the startup/destruction
> phases of a component.
(hmm.. not sure if I understand the hierarchical containers part)
ComponentFactory is only half of the solution though. It manages
instantiation and decomissioning of a component.
For Cocoon for example, changing the factory isn't enough to
implement the RequestLifecycleComponent marker as its needed to be
done at access time (ie. in the handler, of which there are many different
types).
It also makes it difficult to insert markers (like Instrumentable
for example) mid way inbetween the standard ones without
duplicating code or taking the test for each standard marker and
putting it in a method that's called by a subclass individually - but
that's not much different from the ComponentMarker idea, just hard
coded.
Plugging in one's own ComponentFactory also has the same problem
you mentioned of support - each container I've seen so far have their
own factory classes (?). The container would need to support
custom factories.
> I think that is more effective, less intrusive, and more stable than
> a callback mechanism. It is not that easy to enforce the proper order,
> or same order on a component's lifecycle when it is extended in this
> way.
Yes, enforcing proper order is difficult without some validation
mechanism. I agree that's something easier to do if we used an extended
ComponentFactory with an immutable startup order.
I'm probably a bit green with it all, but I think a custom factory is
not enough if we want a general solution that covers all bases. Plug
and play behaviour, while generic and perhaps a bit too dynamic
solves the current issues (no CM/CS subclassing required/no
concrete CM name changes in client code, supports creation
and access markers, and supports insertable markers).
My major concern is the performance of testing for and looking up
each marker callback.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
