Well, it looks like I might be doing more then what is required here, but
I'll try to give some more comments on the scenario.
I assume you are trying to test an ImplementationLoader for its handling of
duplicate components. If so, then you must simply have to focus on that
'unit' i.e. the ImplementationLoader. You need not test if the loader is
registered or picked up from the registry and invoked. These things you
assume and just start with the phase when the loader is actually invoked.
Yes, I'm trying to check for the duplicated components, and I have added
code to handle that inside CompositeLoader.java
Through the mock reader you only need to feed those inputs that the Loader
actually reads from the XMLReader argument. Basically you provide mock
inputs just to the Loader and test how it handles these inputs. So in your
case you might be feeding in duplicates to see if the loader is able to
detect this.
So, I'm trying to mock the necessary reads just to check the duplicate, and
the way I was thinking to do this was to provide mocked reader that would
return two components with the same name,
but while loading the composite, compositeLoader will pass control to
various other loaders, and then will fail inside ComponentLoader with
inrecognizedElement exception trying to get a loder for the <
implementation.java... element.:
Code where it starts passing control to the registry to load other ares of
the scdl returned by the mocked reader:
switch (reader.next()) {
case START_ELEMENT:
ModelObject o = registry.load(parent, composite, reader,
deploymentContext);
Chain of control:
CompositeLoader
LoaderRegistryImpl
CompositeLoader
ComponentLoader
Where it fails in ComponentLoader
try {
Implementation<?> impl = loadImplementation(parent, reader,
deploymentContext);
registry.loadComponentType(parent, impl, deploymentContext);
So, my question is more around, how can I test the CompositeLoader without
having to go that farther in the code chain where other things are required
?
I'll take a look at the read resources Jim sent and see if those give me any
more ideas...
--
Luciano Resende
http://people.apache.org/~lresende
On 1/23/07, Jim Marino <[EMAIL PROTECTED]> wrote:
On Jan 23, 2007, at 9:00 AM, Jeremy Boynes wrote:
> Isn't this a problem in the verify/build phase rather than the loader?
> --
> Jeremy
>
We already support this in the build phase. Ultimately this function
would be moved into the verify phase but since we don't have it yet
and the change is minimal, we can get it in and move it once I get to
separating the phases.
Jim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
