Im see breaks now. First I did not realize that the WSDLs were generated
on startup I was attaching to tomcat too late.
However I don't see how ParamReader.getParameterNamesFromDebugInfo() would
work with either classes or interfaces when only one entry is put into the
method map.
Dan Diephouse wrote:
I think the ParamReader doesn't work with interfaces. If you wanted to
create a JIRA issue for this, that would be great.
I'm not sure why you aren't seeing breaks in SpringServiceConfiguration
and DefaultServiceConfiguration. The ObjectServiceFactory shoudl cycle
through both of those to see if they have an answer. I just tried it in
my IDE too and I'm able to see
DefaultServiceConfiguration.getInParameterName get called.
- Dan
Stuart Barlow wrote:
The WSDL is generated on startup (maybe Spring bootstrap).
The ParamReader which uses the ClassReader.getSignature() method is for
example generating the method signature...
logon(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)J
For the method...
public abstract long
com.peopledoc.jura.LogonManager.logon(
java.lang.String,
java.lang.String,
java.lang.String,
java.lang.String,
java.lang.String) throws java.lang.Exception
However the static ParamReader.getParameterNamesFromDebugInfo() creates a
new ParamReader(c) which does not populate the private member Map
'methods'.
The private member Map 'methods' is only populated from the readCode()
method which is never called. And even then it only calls
methods.put(methodName, info) once.
So I guess there is a bug or two in the ParamReader class? Or I might be
wrong. Shall I raise a jira issue?
Stuart Barlow wrote:
I have added the XFire source code to intellij and have set breakpoints
in the SpringServiceConfiguration and DefaultServiceConfiguration
classes
but it never breaks on them.
At what point is the WSDL generated? Is it ever cached?
Stuart Barlow wrote:
But with Aegis mapping files I would have to create a mapping file for
every service I expose and a method entry for every method. This
kind of
kills the dynamic and agile nature of XFire.
Can the dynamic runtime WSDL generation use reflection to get the names
of parameters?
I was looking at the DefaultServiceConfiguration.getInParameterName()
and it calls ParamReader.getParameterNamesFromDebugInfo() which
should do what I want so maybe I dont have debug turned on.
Ill step through the xfire code and see where it goes.
Ahah I am using Spring so the DefaultServiceConfiguration never gets
used
and so never gets to the ParamReader.getParameterNamesFromDebugInfo
Dan Diephouse wrote:
2. Create mapping files (see the Aegis Binding section) and specify
the mappedName for your parameters
--
Stuart
