First off, I would like to say thank you for your efforts. It's getting a little late now, here in germany at least, so I will take a closer look at your answers tomorrow.
> -----Original Message----- > From: Stephen McConnell [mailto:[EMAIL PROTECTED] > Olaf Bergner wrote: > > >As a proof of concept, I am currently working on converting a small web > >application of mine to merlin. Since the business logic is completely > >separated from the presentation layer I thought about transforming said > >business layer into avalon components to be managed by merlin. The > >presentation layer uses webwork2 which I find to be a great solution and > >thus I would be very reluctant to discard it. > > > > Just a note - I'm actually interested in the potential of embedding > merlin inside webwork. So am I. Webwork is a great, lightweight solution to building a flexible presentation layer. What's more, I do recall a preliminary solution to embedding custom component containers into webwork2 being mentioned on the mailing list a few weeks ago. In this particular case, discussions were spurred by the prospect of being able to utilize the spring framework. Still, it goes to show that there's interest in adopting other IOC solutions. > >(1) I have to set up an embedded merlin kernel/container/whatever (well, > >what exactly do I have to set up?) in a servlet. > > > > You need to setup either: > > (a) an embedded kernel, or > (b) include you web app in a merlin container > > >Is there some canonical way of doing so? Probably not. For the time being, I would rather opt for (a) ;) In the long run, I would probably be all for (b). > Yes there is (for both). > If you embedding the kernel in a webapp - its reasonably strait forward > and there are a few people who have already done this with Merlin 3.0 > and with the new 3.2 snapshot (which makes the embedding process a lot > cleaner). If you go for the second option - then Timothy's email > provides a good summary. Yes, I had a look at the code under web/ prior to posting to this list, but it's - as you realize - quite the opposite of what I am trying to do right now, namely embedding merlin into an existing solution. > >(2) I will have to store a reference to this merlin thingy in the JNDI > >context or servlet context. What exactly would I put there? > > > > Typically you would put either: > > (a) the kernel instance, or > (b) the root block, or > (c) a specific named block, or > (d) a custom service manager that wraps (a, b or c) Referring to (b) I do realize that the code in AbstractMerlinTestCase seems to imply that a given kernel's root block makes for a good entry point into the merlin world. Am I mistaken in this? If not, what exactly - in code, if possible ;) - do I gain from obtaining a reference to such a block? Is it possible to ask a block for a (named) component managed by this block, i.e. something along the lines of final CustomComponent component = (CustomComponent) block.resolve() ? And (c) seems to imply that there is some way of asking merlin not only for the root block but for a specific named block. Is this true, and if so, how would I get such a named block? > Also keep in mind that the Directory Project are working on a JNDI > InitialContextFactory that includes an embedded Merlin instance (part of > the Eve product) so this could also be leveraged (maybe - we would need > to check with Alex on this). This sounds exiting, yet I never heard about the Directory Project, nor Eve. Any links? > How much control do you have over what resources are made available to > the Action? Does it reference the request/session/app context? Can you > supply parameters? Setting up a servlet to recieve a block, or even a > specific set of services is not so hard - so supply on info to the > Action is the primary question. Webwork2 - I cannot comment on webwork1 - allows very easy access to page/request/session/application context. What's more, Action classes may well easily be parameterized, either statically via params declared in xwork.xml or dynamically using xwork's concept of the OGNL value stack. This is not an issue. > >These questions are probably rather trivial, but the available > documentation > >concentrates on solutions which live entirely within merlin. > This leads to > >the impression that merlin is a rather closed system which does > not easily > >allow interfacing with "outside" code. > Ouch! I do honestly think that merlin is one of the most impressive pieces of software I have ever seen. This is not intended as casual flattery, but I mean it. You did a great job. That being said, I just wanted to illustrate how a non-expert programmer like me might feel repelled simply by the inability to easily interface with merlin. While a more experienced programmer will probably feel confident with letting do merlin most of the work, and will be able to think of ways to achieve this, novices - or people migrating an existing app - might find themselves asking questions like "Now, I spent a considerable part of my live building this ultimate user-manager, perfectly secure and what not, and now it's gone to live somewhere else?". > Not at all - the Merlin system provides everything you need to do what > your talking about. Its just that the focus has been on the core with > respect to documetation. A working embedded servlet example is somwhere > on the shortlist - and an overall Avalon HTTP solution is high up on the > agenda. But even higher are the subjects of a new release, the > profiling aspects (which link into JMX), subsystems replacement (e.g. > logging), etc. But these itrems also play into the HTTP space in that > they are central to the notion of turning Merlin into a web server > simply by adding the right facilities. So much to do, so little time ;) Just try to keep your head one inch above the surface. Honestly, while not being an expert in this field, I do feel that JMX would be a viable road to follow. How about utilizing the commons-modeler package? > (a) dynamic service aquisition is available yet (i.e. lookup of a > service without declaring a dependency) bu this is easy to do if you > emabedding merlin Could you elaborate on this? > (b) embedding merlin in merlin is a non-trivial exercise (mainly related > to logging - and some refactoring that will be required in this area and > additional work on replaceable facilities) Glad you say this. I was starting to think I am just being stupid. Cheers, Olaf --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
