Gary Shea wrote:
Based on the feedback you provided earlier - its clear that some some (a) documetation is needed about Merlin bootstrap, and (b) some self-integirity tests are needed during bootstrap so we can issue appropriate messages to the user.I'm progressing slowly towards merlinization. Generally pleased with how things will work once I get there... it's getting there that's tough!
Great - I dodn't thing that parsing was a problem - but I know that the current exception reporting concerning location and presentation of info from a configuration fragment could really be improved. For example, using ConfigurationUtil.list( config ) you can create a string representation of the configuration related error - its this sort of info that needs to be included i the exception report. In addition, I know that the source filename of the configuration file (.xinfo, xprofile, .xconfig) is not terribly helpful. Something more is needed in the factory classes. With those two things in place the reporting on config related erros should improve significantly.One major problem is getting feedback about problems with the .xinfo files. I haven't pinned it down yet, but it appears that an error in the xml that prevents parsing will not be reported. Instead I get the generic message that no resource can be found. I've been modifying bits of code to report more exceptions and it's helping a bit.
One more know issue/improvement concerns the assembly of componet types that are not declared in a jar manifest. Currently the exceptioon just states - "cannot resolve a depedency" or something like that - and thjis needs to be updated so that it is dead clear that the componet type wasn't declared as a compoent, etc., etc. I.e. make it easier for the user to nail things down fast. I've also been thinking about a pre-execution app - something that simply takes a kernel defintion and runs things though the validation mode just to see that everything is resolvable and deployable.
This is code that was introduced relatively recently. Berin is the guy who know s this stuff insdie out - but he's rather busy at the moment. The testing I have been doing is heavily centered on signleton services (i.e. a single instance of the service relative to a partiuclar name). The pooled and per-thread lifestyles are primarly to support applications like Cocoon. The code has been tested but only at a technical level (i.e. the stuff in playground word fine - but not real deployment tests just yet).The current struggle is with pooling. After converting an IllegalStateException that only included the exception message to a CascadingRuntimeException (in DefaultLifestyleManager.getHandler()), I found that the PooledLifestyleHandler is being called with a null poolManager argument. I take it this code is known to work, indicating that the problem is in my stuff somewhere?
More! Gee, setting to debug means your getting a lot of information already! I have to confess that sometimes what I run up something different its just nice to watch Merlin doing all of that work for me. On the other-hand, if something goes wrong the overhead on tracking it down is too high - need to get this lower (more explicit) before releasing something.In general I'm pleased with the amount of information available from merlin with everything set to DEBUG. Still, more is better this early in the learning curve!
Following on from out discsusion about the profile abstraction stuff - I'm started on the seperation of profile and appliance. Some of this is already committed and there is more comming later today. As soon as the API feels right I'll post an update on this.
Cheers, Steve.
Gary -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
