Graham,
An interesting conundrum! Using the correct API programming model, this
wouldn't happen. But of course, our test suite does have non-API
programming examples.
The no arg ctor DescriptionImpl() is the default one, so it does not
initialize the ext reg field. The API provides
WSDLFactory.newDescription() and the implementation of this will call this
ctor then initialize the ExtensionRegistry field. This method is used in
the parseDescription method in the reader impl.
I see from your last response, you have found the same solution used in
some of the other test cases:
DescriptionImpl desc = new DescriptionImpl();
desc.setExtensionRegistry(new PopulatedExtensionRegistry()); <--
emulates the API behaviour
.......
There's nothing to stop anyone using DescriptionImpl(), but of course this
is an 'internal' class so using this ctor directly is not supported...it's
not part of the Woden API.
I could put some code in ComponentModelBuilder to check for the presence of
an ExtReg before attempting to build any component model extension
properties, but this seems like supporting non-API usage via the back door.
I notice that DOMWSDLReader has some code that checks if the ExtReg
obtained from the DescriptionImpl object is null, but this is actually
redundant as it can never be null - at least, not during the path from
WSDLFactory.newDescription -> WSDLReader -> ComponentModelBuilder.
A user could legally do this with the API:
Description descComp = reader.readWSDL(wsdlLoc);
DescriptionElement descElem = descComp.toElement();
Description descComp2 = descElem.toComponent(); <-- OK
descElem.setExtensionRegistry(null);
Description descComp3 = descElem.toComponent(); <-- OK at the
moment
Our existing Woden implementation is based on parsing a document and so the
component model is only ever initialized once. Hence the code above will
not cause an NPE, because the ComponentModelBuilder code does not run
again on the second call to toComponent(). However, our next implementation
step is to consider use cases that modify the WSDL via the API, in which
case the second call to toComponent() should re-run the
ComponentModelBuilder code and probably will result in an NPE. By then I
expect I will have redesigned the extensions architecture and done away
with the ComponentModelBuilder class anyway.
For now, just use your solution above. I'll have a think about what to do
with ComponentModelBuilder in the meantime.
regards,
John Kaputin
Graham
Turrell/UK/[EMAIL PROTECTED]
MGB To
[email protected]
27/01/2007 00:23 cc
Subject
Please respond to re: [WODEN] InterfaceOperation
[EMAIL PROTECTED] questions
he.org
When the following code replaces the toComponent() line in the original
code, this prevents the NPE:
ExtensionRegistry er = new ExtensionRegistry();
er.setErrorReporter(new ErrorReporterImpl());
fDescriptionElement.setExtensionRegistry(er);
fDescription = fDescriptionElement.toComponent();
I confess can't yet see the necessity for in architectural terms, so would
still like reassurance that this is by desgn?
Also, do you think is NPE is reasonable if the above code doesnt appear ?
Many thanks!
Kind Regards,
Graham.
Graham Turrell/UK/[EMAIL PROTECTED] wrote on 26/01/2007 17:24:33:
>
>
> Hi John,
>
> Could you answer a conundrum I'm having with the unit test for
> InterfaceOperation component test suite as part of WODEN-54 ?
>
> I'm getting an unexpected NPE on DescriptionElement.toComponent() after
> doing the following:
>
> private DescriptionElement fDescriptionElement = null;
> private Description fDescription = null;
> private InterfaceElement fInterfaceElement = null;
> private InterfaceOperationElement fInterfaceOperationElement =
null;
> private final String INTF_NAME = "interfaceOperationName";
> private final String INTOP_NAME = "faultName";
> private URI fPattern = null;
>
> fDescriptionElement = new DescriptionImpl();
> fInterfaceElement =
fDescriptionElement.addInterfaceElement();
> fInterfaceElement.setName(new NCName(INTF_NAME));
> fInterfaceOperationElement =
> fInterfaceElement.addInterfaceOperationElement();
> fInterfaceOperationElement.setName(new NCName(INTOP_NAME));
>
> fPattern = new URI("http://www.w3.org/0000/00/wsdl/in-out";);
> fInterfaceOperationElement.setPattern(fPattern);
>
> fDescription = fDescriptionElement.toComponent();
>
> I have (I believe!) checked against the spec that all the mandatory
> attirbutes and properties for <description> <interface> <operation> are
set
> in the above code. So either I've missed something in the spec or there
is
> a bug in the code.
>
> The reason for the NPE is that when toComponent() is called, the
> ComponentModelBuilder calls its method
buildInterfaceOperationExtensions().
> The first thiing this does is
>
> ExtensionRegistry er = fDesc.getExtensionRegistry();
> URI[] extNamespaces = er
>
> .queryComponentExtensionNamespaces(InterfaceOperation.class);
>
> This therefore assumes that an ExtensionRegistry has been created
> (presumably via Description.setExtensionRegistry())
>
> So my questions are:
> - why does the ComponentModelBuilder code insist on an ExtensionRegistry
> having been previously set on the Description? (I didn't expect it to be
> mandatory?)
> - if this is a correct expection, should
> buildInterfaceOperationExtensions() really throw an NPE?
>
> Any observations would be very welcome from all ! Many thanks.
>
> I'm poised ready to complete WODEN-54 with a final commit, hopefully
> including a solution to this, but if not, will open another.
>
> Kind Regards,
>
> Graham Turrell
>
>
> ---------------------------------------------------------------------
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
