Richard Wallace wrote:
On Tue, 2003-01-21 at 18:59, Stephen McConnell wrote:
Basically the Tomcat embedded is packaged as a component that provides a web application publication facility. Other components can declare their dependency on the web gateway and use the service provided to publish into the service a web application. Typically the publishing component provides a reference to itself as part of the publication criteria and the established web application interacts with the publishing component and any component it establishes.Wow... the only part I'm not exactly sure how to do is get the webapp a
reference to the publishing component.
See note below concerning the map!
The map is used to populate the servlet context implementation object so as far as your web app is concerned - its just gets whatever it needs from the context using the ServletContext interface.Great, thanks =). After looking over the API it looks really slick. The only question I had was what is the Map parameter in the deploy()I'll look itThe osm.net content is available to sponsors under an open source license (basically the process at osm.net is something equivalent to a managed open source environment - where managed refers to a process of a lot more top level design and some specific objectives concerning deliverables).
over. Is the source code available?
Anyway, once the package is updated to Merlin 2.1, I'll send you a copy of something off-line to help you get going.
methods for?
Sounds to me like you should be creating a Block instead of stuffingAhh... ok, I think I get it now. I'll play with this some tomorrow.
around with bootstrapping.
1. create an EngineClassLoader
* this means referencing externally located jar files
containing the components you want to use
* if the web app is not running as a component within
Merlin then you will need to create the logging system (see
the engine test case in the assembly package for an
example)
2. create a block
* create a appliance context and populate it with
everything it needs
* use the engine to create the block using the appliance
context as an argument
see DefaultBlockLoader.createBlock( ...) for an example
3. start the block
That way they are all still running in the same runtime so even havingKeep in mind that in a distributed Merlin environment your component will NEVER "do remote" - it will just "do" and the remoteness is something completely hidden.
to do "remote" connections shouldn't be to much overhead.
Not sure exactly what you mean here. The way I was planning to use remote components was create a proxy for them (something like AltRMIComponent or SOAPComponent, etc.) and instead of configuring Merlin to create an instance of ActualComponent. Am I missing something?
Nope - your not missing anything. What you saying is the same thing I do here.
All the kernel does is basically setup a few things which are logically singletons (e.g. logging), creates the containerment model (via the block loader), and kicks it into action. The kernel helps when you are not running inside an existing component.That was where I fist looked - but this is actually being handled by the DefaultBlockLoader before a block even gets instantiated. Basically the block loader goes through the process of building the entire containment scenario (classloaders, blocks, sub-blocks, etc.) and publishes information back into the kernel using urls. The url creation is where you hitting a problem because the URL in question is simply a URL to a local instance but the handler has not been registered. There are several ways of registering URL handlers and the current approach is not 100% satisfactory - in fact I've looking over code in the source resolver package in Excalibur as a possible alternative approach that would be more consistent with the Cocoon project.
So the best way is to avoid using the kernel and just create the block as stated above (at least for the mean time).
Thanks again for all the feedback. I _really_ appreciate it. =)
No problem. Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
