Filip Defoort wrote:
Stephen McConnell wrote:
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 service 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);
}
Ohh .. that looks familiar!
(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 ?
Invoke resolve() on the block and you get back a proxy the implements the services by linked to the respective provider components.
- 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...
There was but I removed it during the 2.1 to 3.0 transition. I wanted to simplfy the Appliance and Block interfaces as much as possible. I don;t see any immediate problems with adding block.getAppliances(): Appliance[] and as a block is an appliance, I would leave it up to the client to do a type test (i.e. no need for getChildBlocks() ).
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...
Alex posted yesterday a bunch of sources dealing with rationalization in this area. Also, the repository key should be to the merlin repository (not maven - but wit the potential to override the setting).
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..
OK - now I understand. I though it was safe to assume ${user.dir} as non-null. We can deal with this as part of the refactoring.
Setting merlin.base.dir in the Map obviously overrides the value altogether, but I guess
the base should be checked for null...
Yep.
Steve.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
