Hi
Yeah, I agree that it will get messy. This behaviour is the default, last-ditch behaviour. If you want name the capabilities something else you can override the generated name in the muse.xml, which is really the way it should be done. The default way is there so that people don't have to know about muse.xml to use the tooling; they can just create a wsdl and have the tooling generate everything else. If a person like this is creating a wsdl that has hundreds of capabilities, well, I think this is an advanced user who would be able to grasp the muse.xml format and dictate how the implementation files would be named. It should also be creating a MyCapability and IMyCapability, since if it was the Impl way (which it was until I changed it) you'd run into filename clashes.
On the second point, I'm not sure how the mapping would be done since a class will have multiple methods (operations), so how would the name of the operation match the class? The relationship is meant to be handled (by default) by converting the namespace to a package name. The operation names carry over as well, so those should also be a good indicator how the generated code relates to the WSDL. I might be missing something here, so if you have a proposal on how to handle the naming, I'd be open to it. I realize that having worked on this stuff for a while my idea on what makes sense might not be the right idea anymore.
Thanks,
Andrew
Andrew Eberbach
Autonomic Computing
(919) 254-2645
T/L: 444-2645
[EMAIL PROTECTED]
| "Vinh Nguyen \(vinguye2\)"
<[EMAIL PROTECTED]>
10/16/2006 01:40 PM
|
|
I agree. From a coding perspective, the way that wsdl2java creates java
files can get quite messy. I would think that by default, all
capabilities for a particular resource should be grouped into the same
package, unless the muse.xml file is modified to specify otherwise. But
currently, wsdl2java creates one package for each capability, based on
the namespace. In effect, if I had one resource with hundreds of
capabilities, then I'd have hundreds of packages for the resource
implementation. And, each package would basically have only two
classes, MyCapability and MyCapabilityImpl.
Also, the default class names that wsdl2java creates should somewhat
match the operation/message names associated with the capability, as
defined in the wsdl. This would help make clearer the relationship
between the operations defined in the wsdl and the capabilities defined
in the generated muse.xml file.
-----Original Message-----
From: Steve Jerman (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Friday, October 13, 2006 7:50 PM
To: [email protected]
Subject: [jira] Commented: (MUSE-85) Possible sample project -
System/Device
[
http://issues.apache.org/jira/browse/MUSE-85?page=comments#action_124422
10 ]
Steve Jerman commented on MUSE-85:
----------------------------------
[[ Old comment, sent by email on Wed, 30 Aug 2006 14:53:34 -0700 ]]
So the wsdl2java file creation creates files..
The package name is taken from the Namespace, but the actual Java files
created (which seem like one per resource rather than one per
capability) are called MyCapability.java and MyCapabilityImpl.java.
Looking at the code, this seems to be hard coded.
Steve
> Possible sample project - System/Device
> ---------------------------------------
>
> 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
> Fix For: 2.1.0
>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
