Schaible, J�rg wrote:
Hello Avalon users, meanwhile I have the merlon demo running in my webapp, but I a somewhat swamped with the complexity. I created my own kernel loader, set both class loaders to the loader of the servlet, set the working home to my webapp's home put there the demo.xml that is automatically read during initialization. Looking at the log messages, anything is working fine. The only thing - I am not sure, if I really need this complexity for a request/response based environment.
The bulk of the complexity you are seeing a result of (a) a moving target, (b) not much in the way of samples, and (c) the embedded setup model which is not yet complete.
I think your going in the right direction! The real benefit kicks in what you stop thinking about the component construction side. You can forget about dependencies completely - forget about what lifestyle a component supports, forget about complex configurations and setting all of this up. You can also forget about the potental for runtime failures due to component depedencies that cannot be resolved (because all of the above is handled automatically for you).Looking at the Avalon framework itself, it seems to offer a simple, but mighty base for a service infrastructure. With "Developing with Avalon" (DwA) a nice documentation exists, although it refers ECM. "Although", because running Avalon 4.1.3 and Excalibur 4.1.3, a lot of deprecated API of the Avalon framework is accesed by ECM. At this stage I asked myself for the first time, if am I going into the right direction.
You don't!
Looking into the mail archives and reading a lot of the messages and looking at the Wiki, I got the impression that Fortress is the successor of ECM with an advanced lifecycle approach, but the real development is currently done for Merlin. While it is perfectly understandable, that documentation is not the primary task at this stage, for newbies it is nearly too much to get even the basic ideas behind all these new interfaces and services from these examples to get anything useful running at all. E.g. for the running merlin demo: How can I access now the services?
Ok - that needs some explination :-)
Keep in mind that for the moment your thinking from a coontainer side perspective. You have established the kernel which means that your component logic is established. There is nothing more you need to do. The rest of the story unfolds on the component side. You components (which will be activated as needed) just interact with classic context, configuration, service management artifacts.
There have been a bunch of changes introduced recently concerning service reference expressed as URLs. There were some issues with the initial implementation that caused conflicts with Tomcat. The result is that the URL management model is being totally rewritten. The URL generation side is now implemented in the assembly package - but service resolution using URLs is still in progress. This is not a problem when Merlin is triggering component activation - but in your case your in a Servlet which isn't under control of Merlin. This is where service URLs come in - you servlet will (in the near future) simply request the service it needs using a service URL and Merlin will take care everything necessary to establish that service.I just have a DefaultKernel object, but somehow I am missing the factory class.
Merlin has two principal sources of information
Merlin does not to use the complete role concept described in DwA. This seems to be replaced by the Assembly with the concept of the Engine, Resource and Type. But I have no idea, what Interfaces I have really to define for a service, that is later on manageable.
(a) the deployment information described in the blocks.xml file
(b) the criteria expressed in a <classname>.xinfo file
The services exposed by the components are declared in the .xinfo file. For example:
<type>
<info>
<name>my-component</name>
</info>
<services>
<service type="org.apache.avalon.playground.SimpleService"/>
</services>
</type>
Also the idea of an Appliance is vague, I am currently not sure, how to identify and separate in my real world between Service and Appliance .. or are both services and the difference is that the Container contains Appliances, but the Appliance does not contain other services?An appliance is an object that a container implementation uses to manage component instantiation. It takes care of two aspects of component establishment - lifecycle and lifestyle. Lifecycle management concerns the application of a series of lifecycle stages. In classic Avalon these stages include things like logger assignment, context, configuration, servicing, etc. A partiular lifecycle stage is known within an appliance as a strategy - the default strategy is the Avalon 4 model although an appliance can support non-Avalon strategies (e.g. Servlet, CORBA Interceptor or Initializer, etc.). The second function of an appliance is to provide lifestyle management - e.g. singletone, per-thread, transient, or pooled component implementation policies.
Keep in mind that the appliance abstraction is something you should not need to be concerned with unless your planning on doing something that cannot be expressed using xfiles (which would be unusual).
If the type manager does not know about your component - then its because (a) you have not defined a <component-class>.xinfo file. The type manager will attempt to create this for you providing the .xinfo exists - if it does not then the type manager does not know its a component. In the log you should see information from the type manager as it registers know components - if you component is not being listed - it means that it is not being recognized as a compoent.Currently I try to setup a HelloWorld appliance that is loaded directly from the file system and not from within an archive. I assumed, that the classloader of the underlying application would be used and I defined therefore not a special <classpath> tag in the block.xml, but creating the ContainerDescription with the DefaultContainer, the creation of the Profile fails, since the TypeManager does not know my Appliance interface demo.service.HelloWorld ...
No problem with the above providing your component has an .xinfo file associated with it.
<block>
<implementation>
<appliance name="standard" class="demo.service.HelloWorld" activation="startup">
<context class="demo.service.HelloWorldImpl"/>
<configuration>
<message>Hello World block descriptor.</message>
</configuration>
</appliance>
</implementation>
</block>
Yep - there is a lot of documetation that is still needed. This is not in place yet because its a moving target - I'm currently working on the block implementation stuff related to service URL exposure (should be done around the end of the week). This will allow imcomming HTTP requests that include service references (together with queries, refs, etc.).Debugging the code I also recognized the different entries in the Context with "urn:XXX" and that they are also used to overload the standard behaviour at initialization. But again, this is only usable searching in the code ...
I'm guessing this is a missing .xinfo. If that does not fix the problem please post a log of the activity with system debugging enabled.Looking at the time I already spent and the results I reached, I am currently really somewhat frustrated. Any help welcome ...
Cheers, Steve.
Regards, J�rg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
