> > How much of this is defined for an interface, and how much is
> > defined for the implementation. Can you only require an
> > interface implementation, or are you allowed to require a
> > specific interface implementation? (should be the former, but
> > is currently non-defined for a lot of software)
>
> MetaInfo is separate from interfaces, or at least should be.
keyword here (and most of the discussion) "should". How much should you
push avalon users towards the "best" way to do stuff?
(how much are we api, how much are we framework? etc etc)
> > > Lastly, the lifestyle info--which I believe is where you are having
> > > problems coming to an acceptible abstraction.
> >
> > Well, deciding a component offers only one service is
> > probably quite a problem for some people (currently this
> > doesn't have to be). This is one of several per-container
> > choices that don't fit in the list you made yet, methinks.
>
> It's cleaner that way. SOC and all that.
Linux Torvalds wrote something like (paraphrasing here) "not many people
are able to work with properly designed software all the time, or even
most of the time".
You have to use MFC, don't you?
If there's this piece of software that performs multiple services (say,
JBoss), and you want to wrap it for use in avalon, well...
> > > The reason I have to ask about factory method is that if a
> > "component"
> > > instance cannot be reused, why is it created as a component? There
> > > are other more effective ways of dealing with those objects.
> >
> > ie ComponentManager, right?
>
> Huh?
Factory is a creational pattern we replaced with something better -
ComponentManager. Different setup, overlapping use case.
> If you have to go through a full lifecycle for an object that is created
> with the interfaces and contracts of a component, but it cannot be
> reused or shared, then we have a problem. The Cocooners can tell you
> beyond a shadow of a doubt that such a "component" is a major
> performance
> sink.
What if you have a singleton framework that uses factories throughout?
Anyway, you'll get my point now...
> The concept of factory I have in the table is the same concept that
> is in the ECM. One instance per request, never reused.
>
> The reality is that the Poolable Component, ThreadSafe Component,
> and Per Thread Component all use factories to generate the instances.
>
> It is more like the Factory in the pool package.
Ah, okay.
> > And what is "lifestyle" here? It seems that part of the
> > problem is the wide definition. Seems you've defined it as
> > "possible creation and usage scope" here...
>
> Yes. That is always what I have meant when I coined the term
> lifestyle--Refering to the creational policies.
okay:
The Component lifestyle defines the creational policy for Components.
That needs to go on the website =)
> > possible component scopes
> > -------------------------
> > (from narrow to wide)
> >
> > request - one instance per request (perrequest)
> > thread - one instance per thread (perthread)
> > container - one instance per container (no mapping to current setup)
> > classloader - one instance per classloader (singleton)
> > system - one instance per JVM (in reality per group of
> > classloaders
> > managed by the container, as you cannot expect a
> > container to be only used in situations where
> > it is always
> > in control of all the classloaders)
>
> Ok. Currently, we offer scopes of up to the container level.
>
> Anything higher than that level should be delegated to a parent
> container.
When you start talking about common frameworks....
Phoenix does a lot with classloaders (should do more, really). One
benefit would be we can finally create some common components for access
by all applications (or even arbitrarily marked applications).
> We try to steer clear of Singleton by static accessor--which is
> really the only way we can ensure one instance of a component
> per classloader.
Except if your container manages the classloaders (ie phoenix has the
option).
> Static accessors to components are the enemy of Inversion of Control,
> and I really can't think of a real world need for it. To that end,
> I would advise against that approach.
agreed.
> A ComponentManager should not generate components. It should only
> manage
> access to them. That is one of the reasons Fortress was created (to
> migrate
> from ECM). A factory is a tool that a Container can use to generate
> instances
> of components. That is really all it is. ECM is a container, so that
> does
> not violate my statement.
uhuh. Yet a *lot* of software doesn't have a ComponentManager but uses a
factory with a pool added to the mix...just that I would like the model
to have a provision for that....
> > SingleThreaded - any instance outside thread scope would naturally be
> > singlethreaded.
> > related framework interfaces: SingleThreaded
>
> SingleThreaded does not guarantee number of instances, or creational
> policies
> other than it cannot be Singleton. The absence of declaring a component
> as threadsafe is the same as declaring it "singlethreaded".
I wasn't talking about the interface, more the concept within this
particular concern space...
> > reusable - for our purposes, a component that is reusable
> > should be defined as "a component that can be provided
> > with a new context ('ficture') during program execution
> > to alter runtime behaviour". Furthermore, to be
> > completely
> > reusable the entire context should be available
> > for change
> > at runtime. Let's call it "runtime reusable".
> > related framework interfaces: Recontextualizable,
> > Reconfigurable, Reparameterisable
>
> Reusable as I have referred to it above means that the component can
> litteraly be used again. The "Factory"/"SingleThreaded" components
> in ECM does not reuse instances in any way. That is bad.
>
> Anything more than that is adding too much to "reusable". We might
> have to capture that information separately.
you okay with "RuntimeReusable"? I know it's a common concept...just
know no common name.
> > Poolable - multiple instances can live within the same scope; they
> > are reusable.
> > related framework interfaces: Poolable,
> > Reconctexualizable, Reconfigurable, Reparameterisable
>
> Multiple instances in a pool. the scope usually inferred by this is
> "per request". The Pool is an implementation detail of "per request"
> scope of a component.
I think this is limiting. In this "component scope"-based system, a
ThreadPool doesn't fit "request".
> > A component has one or more scopes in which it is usable;
> > "request" is the minimum (and implied). container,
> > classloader and system imply thread safety. If a class
> > implements the Re-XXX interfaces for all the XXX interfaces
> > it implements, this implies runtime reusability. If a
> > component is runtime reusable and the parts of its context
> > that are unique within its scope are thread safe, the
> > component is poolable. Poolable is never implied.
>
> I think we have some stuff here to clean up. First of all, I want
> to not consider the concepts of classloader scopes or any scope
> that is greater than the container.
too bad...phoenix really needs to.
When you want to do guarantee isolation of components you have to use
ClassLoaders - they're the only functionality in java that can guarantee
IoC doesn't break.
> IF there are to be components that need to be shared across multiple
> containers, the child containers should ask the parent for them.
of course. What about a container for ClassLoaders?
> > The component scope MetaInfo for a component defaults to the
> > implied values (which are received through introspection).
> > These can be overridden.
> >
> > So component meta info information is:
> >
> > - implemented work interface (required)
> > - work interface version (wildcard possible)
>
> Only on query. A work interface's version is important to be
> declared properly.
yep. What I ment. I thought "this compiles with GCC 2.94 or higher".
That is ok.
> > - implementation version (optional, default: none)
> > - required work interface implementations (optional, default: none)
>
> Why? A component should not worry about what implements a work
> interface.
> That is the administrator's and container's responsibility.
ease of porting existing 'compatibility crap' that doesn't follow our
rules. Like stuff in Tomcat. You need to specify which implementation
you need as well as which interface version (in practice, these are
coupled in like 99% of software).
> > - required work interface versions (required when above is specified)
> > - optional work interface implementations (optional; for optional
> > functionality, default: none)
> > - optional work interface versions (required when above is specified)
> > - allowed component scopes (optional, default: request)
> > - flag: runtime reusable (optional, default: reflection-determined)
> > - flag: poolable (optional, default: no)
>
> Either we define the creational policy with names, or we infer it with
> properties about the component.
>
> Either a component is thread-safe, per-thread, pooled, or it is by
> pure factory (create and destroy an instance for each request).
>
> If we want to allow the liberty for the conatainer to manage those
> policies,
> we need to instead use propertis. In this case, a component can be
> sharable, threadsafe, reusable, and/or perrequest.
Again, the table you made doesn't have a place to fit all of phoenix in.
My thoughts were just, well, thoughts (which I had while baking
pancakes, talking on the phone, and watching the news at the same time).
Neither will do =)
> > Seems like a reasonable abstraction to me. Coming back to my
> > earlier question, it seems that we should disable inheritance
> > of meta info; redefinition of this meta info for child
> > components should be rather trivial, don't you think?
>
> Absolutely. +1
some points I think we all agree on (ie the discussion is muddy so lets
start with stating the obvious):
- manage versioning in some way (pragamatic support conflicts with clean
design wrt implementation specs)
- "The Component lifestyle defines the creational policy for
Components."
- we call these two "common component meta information"
- we define them through custom meta information rather than through std
java features
- we want an abstraction of the meta information to make porting of
components between containers easier
- we want this to be a part of a more general common ground or
abstraction for containers
- I feel the abstraction should define a way to support any lifecycle,
rather than lifecycles for containers with a limited scope
- inheritance will not be used for meta information as that creates too
many problems
- we instead will provide some tools that autogenerate/morph/edit meta
information (providing features like inheritance where required)
- the abstraction should allow support for multiple ways of defining
meta information, like different xml languages, different sources,
management protocol, etc
- we don't want marker interfaces
- we need to make it quite clear to the average avalon user which
container is best for which situation
I'm going to bed =)
cheers,
- Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
