Hi,
> >** Decorator/Interceptor
> >*** decorate Queue with QueueLogger (to send notification, log)
> >*** decorate Queue with QueuePersistancer (to manage stop(crash)/start,
> >based on Prevayler concept)
> >*** decorate Queue with QueueBounder (to limit size,...)
> >
>
> Three possible approaches:
>
> a) the queue component implementation is a type that declares
> dependencies and receives references to QueueLogger,
> QueuePersistancer, and QueueBounder via a service manager.
No, my goal is to follow "decorator" design pattern, so decorated ignore
possible decoration.
> b) the queue component implementation is a type that declares
> deployment lifecycle stage dependencies and you declare
> the lifecycle stage handlers in the block.xml
>
> c) the queue component implementation is a type that
> declares a deployment dependency on a custom
> contextualization provider in which case you provide
> the provider the will handle the contextualization
> (or any other invocations) against target components
I don't understand b and c.
My goals :
public interface Queue {
...
}
public class QueueImplA implements Queue {
...
}
public class QueueImplB implements Queue {
...
}
public class QueueDecoratorX implements Queue {
...
}
public class QueueDecoratorY implements Queue {
...
}
and in config I like to be able to write :
<stage ...>
<queue class="QueueImplA"/>
<stage>
or
<stage ...>
<queue class="QueueImplB"/>
<stage>
or
<stage ...>
<queue class="QueueDecoratorX">
<queue class="QueueImplA"/>
</queue>
<stage>
or
<stage ...>
<queue class="QueueDecoratorX">
<queue class="QueueDecoratorY">
<queue class="QueueImplA"/>
</queue>
</queue>
<stage>
or
<stage ...>
<queue class="QueueDecoratorY">
<queue class="QueueDecoratorX">
<queue class="QueueImplA"/>
</queue>
</queue>
<stage>
* Decorator like any component have its own configuration,
dependencies...
* I know that <stage> could be <container name="stage-x"> and <queue>
could be <component/container name="queue">...
> >** Composite
> >*** create Composite Queue to manage subQueue (like this I could
> >maintain ordre and use ThreadPool,...)
> >
>
> If the composite queue can get everything it needs from context and/or
> serviceable stages, then your in classic "component" space. If on the
> other hand you composite queue is creating components then your in
> "containment" space. If you in "containment" space (i.e. building and
> deploying components) then you need to working with and extended
> Appliance or Block. My impression is that you could do what you want
> with a custom context provider which would keep things simple.
I'll investigate your suggestion (context provider).
to follow previous sample my goal is ablity to have :
// generate sub-queue by clone a prototype (design pattern) queue
public class QueueCompositeM implements Queue {
...
}
<stage>
<queue class="QueueCompositeM">
<prototype class="QueueImplA"/>
</queue>
</stage>
or
<stage>
<queue class="QueueCompositeM">
<prototype class="QueueDecoratorX">
<queue class="QueueImplA"/>
</prototype>
</queue>
</stage>
or ...
> >
> >*** Stage is compose with :
> >**** 1..1 queue (maybe a decorator or composite)
> >**** 0..n processor (sorted)
> >**** 0..1 Dispatcher (to
> >
> >So Stage :
> >
> >* construction
> >** need to define some context for queue, processor, disptacher (like
> >the name, workdir...)
> >
>
> You can intercept the contextualization stage by creating a custom
> contextualization handler. An example is in the CVS under the path
> merlin/merlin-core/src/test/org/apache/avalon/playground
thanks
> >** assemble/chain the processor(s) and disptacher
> >* life style/algo (simple version)
> >** receive message from any component : other stage (via its dispather,
> >service X like a socket listener...) and enqueue it
> >** select a Thread and wait message from the Queue
> >** take message from Queue and submit it to the chain of processor
> >** if message processing and dispatching is ok then remove message from
> >the queue (ack)
> >
> >Currently I've got a version running under Phoenix but with heavy
> >configuration (Queue, Processor, Dispatcher are managed (lifecycle...)
> >by Stage):
> >* need 'cut and paste' stage's definition in assembly to be able to have
> >several stage (with different name)
> >
>
> No problem - these would be represented as named components.
I know Merlin use well "name" attribute (include in my helloworld
version), it's against Pheonix "cut and paste".
> >* need to define Queue, Processor and Dispatcher dependencies has Stage
> >dependencies, not very flexibeable : when I create a new Processor with
> >other dependencies than the already exists in Stage, I need to modify
> >the source of Stage (java generate .xinfo), all the defintion of stage
> >instance in assembly.xml...
> >
> >And if I choose to try Merlin it's first because Merlin is presented has
> >able to manage sub/custom container. (And I saw the source/config of
> >larm :
> >http://marc.theaimsgroup.com/?l=avalon-users&m=104554030111477&w=2)
> >
>
> If I understand correctly - what you are describing is a dynamic
> component. I.e. a component that is programmatically established
> outside of the general deployment phase. Is this possible? Yes. Is a
> component acting as a container the right place to do it? Yes.
>
> Inside the component implementation declared for the container, you has
> a supplementary default context entry "urn:assembly:engine". This
> context entry is only available to components acting as containers.
> Once you have access to the engine, you can narrow it to the Engine
> interface and use create or locate appliances within the current engine
> (immediate and parent engines). You locate services by locating the
> appliance and resolving the service from the appliance. If this sounds
> like what you want to do I can post additional details (examples are not
> available yet in the doc but test cases are available).
>
> Example:
>
> public void contextualize( Context context )
> {
> Engine engine = (Engine) context.get( Engine.KEY );
>
> // do dynamic stuff based on the operations exposed
> // on the Engine interface
>
> }
>
> See the Engine javadoc for details:
>
> http://avalon.apache.org/sandbox/merlin/api/org/apache/avalon/assembly/engine/Engine.html
I've got lot of stuffs for near days ;-)
> >I've got also an other constraint : production is targetted to
> >september. If you see some incompatibility, hard stuff... please tell me
> >
>
> I don't see any problems based on what is described above. The main
> things appear to be (a) confirming that I understand your requirements
> correctly, and (b) getting in-place examples of both custom
> contextualization handlers and containers acting dynamically.
>
> >and may be give some direction to investigate (fortress ??, custom like
> >Cocoon team done...). Thanks a lot for your help.
> >
>
> My best suggestion is to get together in a pub somewhere in Paris and
> talk about over a beer or two.
With pleasur.
Thanks for your help, to help you, I'll wrote my ideal near (after a
better understand of all you wrote).
> >>>>One problem in the above - Merlin 2.1 does not directly support the
> >>>>Executable interface. Problem is that the semantics at the level of
> >>>>the framework are fuzzy here - what to do if a component implements
> >>>>Executable and Startable? My own thoughts are that this should
> >>>>qualified as a deployment policy - such that policy (a) results in
> >>>>invocation of Startable and policy (b) ignores startable and only
> >>>>invokes Executable. Policies (a) and (b) should be mutually exclusive.
> >>>>
> >>>>
> >>>>
> >>>One case when I have Startable and Executable :
> >>>then component is scheduled (schedule actived with start) but I need the
> >>>ability to run the action handly, so I use execute() (through JMX or other
> >>>component).
> >>>
> >>>
> >>I've been thinking about this in more detail since I posted my reply and
> >>I'm progressively moving towards the position that Executable and
> >>Startable may be more problematic that what I suggested. The thing that
> >>is bugging me is that while a particular component may have a deployment
> >>policy relative to its deployment - we cannot use such a policy globally
> >>because consumer components will need a fully deployed componet (which
> >>means all dependents that are Startable must be started before we assign
> >>references to the consumer).
> >>
> >
> >ok, what is consumer ? (ServiceManager)
> >
>
> More correct is to say that the consumer is the component to which the
> ServiceManager is assigned. Internally the consumer is the appliance
> managing the component and process of assembly is the action of
> assigning appliances (acting as providers) with appliances (acting as
> consumers). The ServiceManager is simply the result of grabbing the set
> of provider appliances and putting them together in a form suitable for
> exposure to a component.
>
> >>As to the existence of Executable via JMX - that changes the picture
> >>because we are taking about an management operation (as opposed to a
> >>potentially inconsistent lifecycle operation).
> >>
> >>
> >>>I'm OK with you, Executable is out of the scope of the Container but aren't
> >>>exclusive with Startable.
> >>>
> >>>
> >>Current conclusion (i.e. state of current thinking that is not
> >>necessarily complete):
> >>
> >> * Given the existence of Startable and Executable within
> >> a given component implementation, Startable shall be
> >> applied and Executable shall be ignored.
> >>
> >> * A component that implements Executable but not Startable
> >> shall be executed following Initialization.
> >>
> >>
> >>
> >>>>I'll put together a tutorial that demonstrates a custom container.
> >>>>
> >>>>
> >>>Thanks.
> >>>I wrote a HelloContainer but I don't see the difference between Container
> >>>and component (if container couldn't use, compose sub-component).
> >>>
> >>>
> >>There is not any difference between a container and a component (as far
> >>as a component implementation is concerned)- the difference rest on how
> >>the component (acting as a container) is handled by its appliance. In
> >>the case of a component acting as a container - it is handled by a Block
> >>- which adds the notions of separation of published services from its
> >>internal component structure (implementation).
> >>
> >
> >Internal component can't access services from outside the its container
> >?
> >
>
> A component acting as a container can access appliance instances and
> services dynamically. No problems here ;-)
>
> >
> >If so, Merlin isn't the solution for my case (this restruction is the
> >main raison why I would leave Phoenix).
> >
> >Other point : may be I should need to create a custom Block, like this I
> >could enforce check of stage. Because inter-stage dependencies is define
> >at the configuration time when I configure the dispatcher of the Stage.
> >
>
> It's possible but probably not necessary. My current assumption is that
> you can do what you need to do via interaction with the engine.
I really need to study Engine capabilities.
> >>It may sound complex - but it makes deployment of all sorts of
> >>components just plain easy and very reusable.
> >>
> >
> >lot of work for you ;-)
> >
>
> But its fun!
Thanks
--
--------------------------------------------------------------
David "Dwayne" Bernard Freelance Developer (Java)
mailto:[EMAIL PROTECTED]
\|/ http://dwayne.java-fan.com
--o0O @.@ O0o-------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
