On Mon, 18 Nov 2002, at 19:35 [+0100], Stephen McConnell ([EMAIL PROTECTED]:
> Gary Shea wrote:
> >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.
> >
>
> 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 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.
The "cannot resolve a dependency" is the one that's making me crazy,
yep! I haven't put anything in the jars yet. Thanks for the reminder
though, I will do it today.
I have to admit that my code changes at this point are basically hacks
to report more information. It would be great if things became clear
enough that I could offer some decent patches but I can't promise
anything :(
> >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?
> >
>
> 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).
Ok, that's useful information. If it helps any, the last useful
information I got is that the DefaultLifestyleManager that is being
contextualized by the DefaultKernel is a different object from the one
that is being called to create the PooledLifestyleHandler! The one
creating the PooledLifestyleHandler has never been contextualized.
Just for your info -- the component I'm pooling is a non-thread-safe
connection to an XML:DB database.
And now back to the code swamps.
> >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!
> >
>
> 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.
I know what you mean. But that's what the logging categories are for,
right? I've got all of them set to DEBUG, that's a recipe for
overwhelming output.... which at the moment is just exactly what I need
;)
> 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.
I'll be interested to see what you've come up with. Right now I just
want to get my first four components working ;)
Gary
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
