You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-dev@ws.apache.org by "Andrew Eberbach (JIRA)" <ji...@apache.org> on 2006/09/01 19:26:28 UTC
[jira] Commented: (MUSE-85) WSDM Test File
[ http://issues.apache.org/jira/browse/MUSE-85?page=comments#action_12432190 ]
Andrew Eberbach commented on MUSE-85:
-------------------------------------
Hi,
The hardcoding is because you're passing in a WSDL file and wsdl2java can't devine the name of the class you would want (it tries its best with the package name: org.cisco.cmp.schemas.2006.07.System). I couldn't come up with default name mapping since not everyone uses URLs for their namespace and if the URL is invalid for some reason I'd have to have some default anyway. That said, there is definitely a way to specify what you want the generated class to be called.
The way to specify the names of the files is to create a muse.xml descriptor. If you're using wsdl2java with no parameters then you are making an Axis2 project and the generated descriptor will sit in WebContent/WEB-INF/services/muse/muse.xml
You can take that one, find the capability mapping you're looking for ie:
http://schemas.cmp.cisco.org/2006/07/System -> org.cisco.cmp.schemas.2006.07.System.MyCapabilityImpl and then change it to your liking.
You can then rerun the wsdl2java tool giving the descriptor as a parameter like:
wsdl2java -descriptor muse.xml
In this mode (which I'll be documenting this week) the tool will iterate through each resource type in the descriptor and pull out its wsdl-file and run wsdl2java against it. The point of interest here is that since you're using the generated muse.xml it references wsdl/System.wsdl so can either change it to reference another WSDL file or just copy the wsdl directory from WebContent/WEB-INF/services/muse/wsdl to live in the same directory as muse.xml
wsdl2java -help and wsdl2java -helpmore give more useful usage messages now.
The reason why I didn't just make a -classname parameter is because:
1) I wanted to keep the parameters to a bare minimum. That's why by default or with -help the usage is the very simplest case.
2) I figured that this is a very special case and that in general most muse endpoints will have multiple types (especially for things like Notification Producers).
Finally, if you want to have a clean descriptor to start from you can use
wsdl2java -dump file.xml
To write out the default descriptor the wsdl2java starts out with. Under the covers I'm actually doing the mutli-resource type case every time, but if no descriptor is specified I have a base skeleton descriptor I start form.
If you have any more questions please let me know. You suggestions and bug reports so far have be very helpful.
Andrew
> WSDM Test File
> --------------
>
> Key: MUSE-85
> URL: http://issues.apache.org/jira/browse/MUSE-85
> Project: Muse
> Issue Type: Test
> Components: Other
> Affects Versions: 2.0.0
> Reporter: Steve Jerman
> Assigned To: Dan Jemiolo
> Attachments: MyCapabilityImpl.java, TestFile.zip, WSDM-POC-Model.gif, WSDM-POC-Model.gif, xml.zip
>
>
> OK, attached isa diagram which shows the model I am trying to create WSDM interfaces for. Also attached is a Zip file with a set of WSDLs. Basically I started with some generated XSD/WSDL and then decided that I should hand code a proto that validated correct and did the right stuff and use that as pattern. The system.wsdl file was the result. I *think* it should create a simple WSDM resource implementation with getResourcePropertyDocument and getResourceProperty operations. It sort of looks like thats the case.
> A few questions.
> What would some code look like that could handle multiple instances of System. Do I need to do anything different?
> Surely the Java interfaces generated are for the ManagedResource? They don't seem to be Capapability implementations.
> Looks like the name of the Java files is hard coded. Is there a better way to handle this?
> I would like to get this sample up and runing first and then expand out to the rest of my model (and all the configuration I have in mind).
> Steve
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org