Olaf Bergner wrote:
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:
Just a note - I'm actually interested in the potential of embeddingAs 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.
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.
Eric Pugh was talking to me about this the other day - sounds like some there could be some value in digging deeper into this.
You need to setup either:(1) I have to set up an embedded merlin kernel/container/whatever (well, what exactly do I have to set up?) in a servlet.
(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.
Yep - the embedding in a web-app is something that can be done now that we have the general bootstrapping model sorted out. In fact I've just done this earlier today (see merlin/kernel/servlet) - its a working work-in-progress but you should get the idea of what's happening.
Typically you would put either:(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?
(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?
No your not mistaken. The root block provides you with access to the meta-model and the runtime state. Through the metamodel you can add containers, compoents, etc. and control block deployment and decommissioning.
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() ?
Invoking resolve() on a block returns a proxy exposing the services exported
by the block. Typically you will do locate( path ) to get a block or appliance
and then resolve aginst the reurrned appliance.
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?
Example.:
Appliance appliance = m_root.locate( "/my-container/fred" ); MyService service = (MyService) appliance.resolve();
Or, you can use relative addresses;
Block myBlock = (Block) m_root.locate( "my-container" ); Appliance appliance = myBlock.locate( "fred" ); MyService service = (MyService) appliance.resolve();
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?
The Apache Directory project is an incubator project that is a result of the
import of the SF ldapd project. At this time they don't have an Apache site
in place but there is info on the old SF site at this address: http://sf.net/projects/ldapd - aside from that there is the directory project
mailing list - and naturally - Alex can provide lots of additional info.
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.
Good.
These questions are probably rather trivial, but the availabledocumentation
concentrates on solutions which live entirely within merlin.This leads to
the impression that merlin is a rather closed system which doesnot 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?".
To-date the documetation on Merlin has focussed on usage by the component developer and assembler. The documetation concerning usage of internal api is not in place - for example - how to embed merlin - manipulation of the metamodel, etc., etc.
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?
It's been a long while since I looked a commons-modeler. WOuld it help at tool level (e.g. JMX generation of descriptors etc. or am I totaly off track)?
(a) dynamic service aquisition is[n't] 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?
If you have access to a block then your basically emprowered to do a lot of stuff. You can reach in a locate nested blocks, appliance instance, resolve blocks and/or applicaes to services, manipulate the meta model, decommission component, modify configurations, recomission, etc. However - this is deep into the internals. Its basically what Merlin uses to do its stuff. If fact - the "merlin" content is rather thin - the real content is in the composition and activation packages.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/ | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
