David Bernard wrote:
long but interesting information, thanks again.
This is definitely in the area of a custom appliance. The appliance code handles all of the things to do with dependency establishment (assembly) - and the Block class (a specialization of Appliance) exists to handle virtual services (i.e. turning a container into a component).* How/When custom container could acquire reference to ready to use sub-component ?
Can you tell me some more about what your ultimate aim is - because in principal you should not need to extend Appliance or Block unless your getting in real deep (in fact an overarching objective within Merlin is to provide sufficient parameterization points such that actual usage of the API should not been needed except in really special cases).
Like I wrote in previous mail : http://marc.theaimsgroup.com/?l=avalon-users&m=105061293530441&w=2
Thanks for the link - helps to get me back in sync.!
I currently work on a little eai. Design concept are based on SEDA and Pipeline (ala Cocoon) approach :
* Structure ** Have a config file that define the services and the graph of stage (may be like Cocoon sitemap + xconf) ** My Project Cocoon Stage --------------> Pipe Queue --------------> Generator Processor --------------> Transformer Dispatcher --------------> Serializer ** Stage, Queue, Processor, Dispatcher are interface
* Ability to enhance Stage's components with some Design Pattern :
** 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. 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
** 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.
*** 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
** 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.
* 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 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.
:-)
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).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).
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).
Current conclusion (i.e. state of current thinking that is not necessarily complete):I'm OK with you, Executable is out of the scope of the Container but aren't exclusive with Startable.
* 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.
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).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).
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.
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!
Cheers, Steve.
Regards.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
