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.

> 
> 
> >I'll look it
> >over.  Is the source code available?
> >
> 
> The 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).
> 
> 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.
> 

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()
methods for?

> Sounds to me like you should be creating a Block instead of stuffing
> 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

Ahh... ok, I think I get it now.  I'll play with this some tomorrow.

> >That way they are all still running in the same runtime so even having
> >to do "remote" connections shouldn't be to much overhead. 
> >
> 
> Keep 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.

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?

> 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. =)

-- 
Richard Wallace
AIM Consulting and Computers
http://www.a--i--m.com

"Providing New Technology,
     the Old-Fashioned Way"


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to