Leo Sutic wrote:
Thanks for the detailed reply - I've tried to pull together the thoughts
I have about this area and really focus on the issue I see surrounding
all of the current Avalon containers and the work/re-organization that
needs to happen.
> Stephen McConnell wrote:
> > Go back to MicroContainer and rip out the lifecycle processing
> > code - put in place something from a common codebase - reduce
> > the duplication.
>
> Agreed - if containerkit becomes the common ground for all containers
> then this should be done. The reason it hasn't been done yet is
> because I wanted to avoid dependencies as far as possible - you should
> only need the MicroContainer JAR. Stupid reason? Maybe. If so, I will
> correct this.
I think packaging is orthogonal to the question of dependencies. I
understand the problem of delivering 2 or more jar files or more instead
of one. But lets assume that you include anything you need from
containerkit into you distribution as a micro-all.jar and anybody that
wants specifics can download micro.jar + containerkit.jar + whatever if
they feel so inclined. I have to deal with the same issue with respect
to the work I'm doing on Merlin (which also ties in i18n, mpool, etc.).
But let's move on - more important things are emerging in this message :-).
>
>
> > MicroContainer has nothing to support components with formal
> > dependencies.
>
> I do not understand what you say here. It is true that MicroContainer
> does not provide any kind of functionality to intelligently wire
> together components based on metainfo associated with the components.
> All that is done programmatically. But I see no problem with actually
> running the component. As you have investigated this - could you say
> what in the environment set up by MicroContainer for the component it
> is that causes the component to fail?
The problem is in the word "programmatically". I have probably something
in the order of 25-35 major components. Of these, my guess is that maybe
3 are components that don't declare dependencies. This means that the
rest assume that the container will take care of the instantiation and
preparation of the application context based on the meta-info
declarations. This means that the 3 components are potentially reusable
- but in fact there not - because Merlin includes mechanisms to capture
default configuration and context information that is "specific" to the
Merlin container. Assuming that this point concerning Merlin difference
could be resolved (which is something I'm working on with respect to the
containerkit stuff), it still means that those components are limited to
Merlin or Phoenix, To achieve reuse within Fortress or MicroContainer
the service that are provided by my components need to be exported in
some way. For example - I have a JASS authentication component (does
keystore related stuff and principal establishment). This component only
makes sense as a reusable component - so its deployment is limited to
contains that understand the notion of a service declaration, and can
provide this to another component that declares a dependency
declaration. If I deviate from that path it means that I'm putting code
into a component or container that ties it to a particular container
model. That's what's cool about Phoenix and Merlin - they don't need to
include container specific code. Ok, confession - Merlin has some stuff
which is container specific - but Merlin II should eliminate this based
on what's going on in containerkit (which is also linked to me twisting
Pete's arm on accession in direction he's not necessarily ok with).
Phoenix also introduces dependencies through patters - things like the
use of BlockContext - which a developer can avoid "if they know what
they are doing". Bottom line - containerkit is about resolving all of
these issue.
So - excuse the rant - and to get back to your question - it isn't the
environment setup that the issue (if I restrict myself to only
non-dependent services), the big problems are (a) microcontainer could
in principal masquerade as a formal component and handle publication of
the services it is providing as a formal component - which would be
super super cool. Secondly (b) microcontainer requires that information
already available in a meta description (.xinfo resource) be re-declared
(i.e. duplicating the logic that already exists). If microcontainer
where enhanced to be "a container that wraps a Avalon based lifecycle
object and presents it as a well-formed component"- then you would have
something really useful - and something I would be going out of my way
to synchronize with.
>
>
> If there are components that simply can not run inside MicroContainer
> I need to understand what MicroContainer can not handle. The idea is
> that while all components should work in Phoenix, not all need to work
> in Fortress, and not all in MicroContainer. Just that all that work in
> Micro works in Fortress, all that work in Fortress work in Phoenix and
> so on. Is it the ability to extends the lifecycle that you lack?
No. Its the formal component contract. If I declare that a component
implements service X, then any container must be able to provide X to
component that declare a dependency on X without duplicating information
inside a component configuration file. The second point is described
above - the issue of ensuring that MicroContainer can provide formal
services to other containers - and this is a area totally in the
gray-zone but it's an area that I think is the most valuable ...
eliminate the concern for which container you are using - as long as the
container provides support for the federation of services in a formal
manner.
>
>
> > NO UNDERSTANDING OF FORMAL DEPENDENCIES AND SERVICES
>
> 1) I'm stupid. Can you be more precise about what you mean by "formal
> dependencies and services"?
The component declares services in a consistent manner. This means some
sort of interface across which meta information is accessible. One
mechanisms is the .xinfo file
(http://home.osm.net/doc/containerkit/org/apache/excalibur/containerkit/infobuilder/package-summary.html).
Another mechanism is for a container to export the services it is
hosting - and that's a work in progress that I would love you to get
involved in.
>
>
> Anyway, from what I guess formal dependencies and services are:
> True. It is utterly clueless when it comes to this, and that was done
> on purpose. The purpose of MicroContainer was to provide a very
> low-committment alternative for Avalon. In particular, it should be
> possible to create components via static factory methods, much like
> one creates SAX parsers in JAXP. All to make it as similar to standard
> Java as possible, and have as utterly minimal impact on the
> architecture of the system it is used in as possible.
Yep - I understand.
In my terminology its a non-dependent component (but I need to qualify
what I mean here) - but more importantly I do think the container needs
to enable the presentation of the object it is handling as a formal
component - then without Pete or I knowing about it - your container
will be running as a component inside Phoenix II and Merlin II. As the
point concerning qualification - what I mean is that I should not have
to re-declare any information already published as part of the component
type.
>
>
> I remember in Avalon-Users that one person had given up on Fortress
> and hacked *Tweety* to solve his problem. This would indicate that
> formal dependencies and services aren't vital, or else my
> understanding of Tweety's level of sophistication is grossly wrong.
That's a case of a customer lifecycle handler - nothing more. That's
fine - I have several instance of similar things. It has nothing to do
with the concept of a container - a utility lifecycle helper - yes.
>
>
> > What about Merlin? - Shouldn't it be included with the three
> > musketeers - or I should I head over to the axis-of-evil?
>
> Depends on whether you want to include SOAP processing in Merlin, I
> guess...
Merlin has nothing to do with SOAP :-)
Merlin is basically a mini-Phoenix - it doesn't run applications -
instead it takes a target component and executes it (and takes care of
any dependencies and dependencies dependencies, etc.). It also include
automated management of default context and configurations - allow the
binding of default context and configuration information into the type
and Merlin will apply all of that so you don't need an assembly.xml or
config.xml - Merlin just figures it all out. And Merlin is really small
(not as small as MicroContainer but much smaller than Phoenix). Merlin
II is a re-write of Merlin that in the pipeline that is totally based on
containerkit. For a glimpse at Merlin II direction check out the package
summary on: http://home.osm.net/doc/assembly/index.html
>
> > I do want a common container solution
>
> Me too, but I do not see how that can be done. What you describe has a
> very high committment threshold. Basically: Create your entire app the
> Avalon way, or forget it. This was the root of the three-container
> approach: Since Avalon comes with so many strings attached, provide
> different containers, where at least one came with little or no
> strings attached. That one was/is MicroContainer.
I think it is possible if we separate the notion of a container
"mechanism" form a container "service" and separate the application
kernel from the container. What this results in is a kernel that runs
containers and containers that run components - and if we are smart
about this separation we should be able to have container hierarchies
where container A contains container B and C, and B is a MicroContainer
and C is a Merlin container and A is a Fortress container and the kernel
is Phoenix or some other a micro kernel.
>
>
> > Can you provide a summary of the different "components" that exist
> in Excalibur.
>
> + Cache - a caching framework, interface and impl.
> + DataSource - a DB connection pool.
> + SourceResolver - a unified way to access data via URIs.
>
> > Very limited validation - no enforcement of a formal compoenent
> > defintion - usefull for lifecycle handling.
>
> *Exactly*
>
> > This has to be solved - existance of different semantic approaches
> > to component management mean that components are designed
> > and implememtated today relative to a target container family. We
> > have two semantic models - the ECM/Fortress/MicroContainer model
> > and the containerkit/Phoenix/Merlin. Either of these two approaches
> > must die or we must make a formal distrinction between them and live
> > with the consequences.
>
> Is this the component-as-service difference?
Nope - unrelated issue.
> I.e. in contaierkit/Phoenix/Merlin all components are what the ECM
> world calls ThreadSafe?
That's a container mechanism (implementation issue). Today Merlin is
limited to thread-safe components - but during development it had full
support for pooled components but with Excalibur re-organization - lots
of talk about changes - etc. I dropped the pool support on the grounds
that I would get to a point where I understood better Fortress/mpool
evolution etc. I'm planning on re-introducing this into Merlin II - but
I would prefer to do this with collaboration from yourself or Berin. It
really not an area I'm into - 98% of my stuff if thread-safe and the
rest is handled outside of the Merlin context. Thinking in really big
balloons - would I would love to see is Merlin broken into a set of
services really focussed (a) auto assembly, and (b) container
hierarchies. From here I would love to see Fortress logic at the
lifestyle level broken out as component factory handlers. I would love
to see MicroContainer appearing as a container somewhere in a container
hierarchy. And finally, I would love to see a container hierarchy
presenting itself to Phoenix as an application. You get an idea of where
I'm heading ... ?
>
>
> Finally, as you say MicroContainer must sometime be rewritten and
> reworked. That is not something I didn't already know. But could you
> tell me in what way?
A lot of clues above - more discussion nees to be on another thread -
the stuff I have concerning Merlin II is really only dealing with the
auto assembly aspect at the moment and even then its not completed.
Merlin II can be supplied with a component instantiation profile and
figure everything out from there - but the code base today is limited to
getting the details together of a preferred application profile. I have
not solved component activation ordering and activation although this
should be solved reasonably quickly. The main work to be done is
figuring out the container hierarchy model which is the critical
element. If the stuff I've done on Merlin II look promising and
something you or anyone else would be interested in collaborating on,
I'll go ahead and commit it into the Excalibur CVS - otherwise its
simpler and easier to maintainer it locally on my machine. Let me know
what you think and don't hesitate to tell me that I'm expecting way too
much from MicroContainer given its prime objective.
Cheer, 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]>
