I guess I need to replace this by some system that passes the Kernel / Root Block(?) / Engine (?)
to the TestServlet and TargetTag so that these classes can lookup components and
use the result of operations on components in their output?
Yep.
The objective was to provide a means whereby a servie could be requested by name together with a bunch of parameters. This would allow actional urls and other such stuff. I never got to try it out in a production environment but it seemed to be heading in a good direction.
As simple as setAttribute("merlin-root-block", m_kernel.getRootBlock() ) and then
block.resolveAppliance("componentname") ? Still a bit confused on what is what
in Merlin ;-)
Hey - I impressed with the progress your making!
Thanks, check this out ;-) :
basic servlet thingy is running; MerlinServlet now adds
getServletContext().setAttribute("merlin-root-block", m_kernel.getRootBlock() );
Then, TestServlet can do something like:
init() {
m_rootBlock = (Block)getServletContext().getAttribute("merlin-root-block");
}
doGet() {
Appliance myAppliance = m_rootBlock.locate("/tutorial/random" );
RandomGenerator rg = (RandomGenerator)myAppliance.resolve();
writer.println( "Random = "+rg.getRandom() );
randomAppliance.release(rg);
}
(I copied the dependency/auto source to a new tutorial/service and threw everything
away except for the RandomGenerator stuff; simply added a dependency in
the project.xml and the correct jar gets included in the war)
Seems to work like a charm :-).
Started updating the jsp custom tags, but I know very little about the JSP stuff, so
I first need to read up on it; but also there I can get to the correct appliance..
Couple of additional questions:
- If I do m_rootBlock.getModel().getServices(), I don't get services that are e.g. declared in the tutorial block -- how do I export services that are declared with <service> in the tutorial block to the / block ?
- Is there a way to "navigate" through the blocks ? E.g. something like block.getChildBlocks(): Block[] and block.getAppliances(): Appliance[] Not that horribly useful, except for building a simple navigator through the different containers and components...
Couple of things I came across during the update:
- in DefaultEmbeddedKernel, getSystemRepositoryDirectory() relies only on System.getProperties(),
there's no way to pass in an argument of some sort (via the Map()); this forced me to do an
ugly
system.setProperty( "maven.repo.local", getInitParameter("maven.repo.local"))
When we need additional parameters in the map - feel free to add as needed.
maven.repo.local would be the only one to add so far...
Remember that DefaultEmbeddedKernel is currently too strongly linked to the Maven context and that a getSystemRepositoryDirectory() should be returning something like ${merlin.home}/system - but I'm still playing with content to support that. In the meantime its using the Maven repo - but that should be considered as a temporary condition. Also, as this comes together there will be a case for rationalization across DefaultKernelContext, DefaultKernel, DefaultLoader, DefaultEmbeddedKernel.
ok..
- in DefaultKernelContext: give a NullPointerException if merlin.base.dir is not given.
Bit surpised about this, was expecting to default to the current working directory...
Can you point to the actual code fragment
DefaultKernelContext.java from cvs, line 240:
final File base = new File ( System.getProperty("user.dir") );
if ( home != null ) {
m_home = home;
} else {
m_home = new File( base, "home" );
}In my case, the user.dir is for some reason empty -- suspect that has to do with the servlet
environment..
Setting merlin.base.dir in the Map obviously overrides the value altogether, but I guess
the base should be checked for null...
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
