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]>
