Ok...
I think i get it. You guys are really helping! Thanks! :)
Considering the named "simple example", which is in the samples dir, the
path followed by the developer would have been:
1. Definition of the WSDL. (with one port type that holds three
operations (FirstOperation, SecondOperation, GetMetadata).
2. While creating the WSDL, some customizations were done:
1. wsdl:definitions (first and second were manually created,
otherwise, everything would be under simple directory, there wouldn't be
simple/first and simple/second)
1. xmlns:first="
http://ws.apache.org/muse/test/simple/first";
xmlns:second="http://ws.apache.org/muse/test/simple/second
"
2. wsdl:types (targetNamespaces followed the previous pattern,
they were also customized)
1. targetNamespace="
http://ws.apache.org/muse/test/simple/first";>
targetNamespace="
http://ws.apache.org/muse/test/simple/second";>
3. The same for the port type section...
3. After that, running wsdl2java would still create the default java
files with default names.
4. The developer then would have to manually create the directory
structure (simple/first, simple/second), copy the default files to each one
and rename them to FirstCapability.java, FirstCapabilityImpl.java, and
so on for the Second...
5. After that, one should update the muse.xml capability's section to
reflect the file name changes.
Is that it? Sorry for so many text... :)
Best regards,
NPKF.
It's just a matter of defining my port types and operations, then running
the wsdl2java, using a customized muse.xml file.
On 9/4/07, Vinh Nguyen (vinguye2) <[EMAIL PROTECTED]> wrote:
>
> Hi Alex,
> If you already have a muse.xml file setup with the correct capability
> class names, I think you should be able to pass it to
> wsdl2java via the -descriptor argument you mentioned. I haven't used
> this myself though, so I can't confirm. The link below has more details
> on this argument for 2.2.0:
>
> http://ws.apache.org/muse/docs/2.2.0/manual/tools/wsdl2java.html
>
> For the last point, I meant that wsdl2java is just a convenience tool
> which helps you generate the stub classes, which you still have to
> modify. So you can actually do it manually without wsdl2java. Just
> create a class that extends the proper base class (i.e.
> AbstractCapability), add your methods with the correct arguments, and
> then add the capability to your muse.xml. Just make sure that your
> methods match the operation signatures defined in your wsdls. The only
> time you'd run wsdl2java again is if you modified your wsdl and want to
> compare the operation signature changes, or to check for added/deleted
> operations. But you can do this yourself if you know exactly what was
> changed in the wsdl. So basically, even if you use wsdl2java, a large
> portion of the work afterwards is still manual.
>
> But for generating the client side proxies, it's better to use wsdl2java
> since it generates a lot of code that would be tedious to do by hand.
>
>
> -----Original Message-----
> From: Alexander Willner [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 04, 2007 1:37 AM
> To: [email protected]
> Subject: Re: WSDL2Java, Capabilities - Newbie
>
> Hi,
>
> > 2) The capability class is given a default package and class name
> > which matches the capability's URI. You can rename the package and
> > class to fit your needs. Just make sure you update its reference in
> > the muse.xml.
>
> is it somehow possible to rename the MyCapability and MyService class
> automatically? Since we're changing the WSDLs quite often we generate
> the classes every day and we've to use perl scripts to change some
> details in the classes every time, this is not very convenient from my
> point of view.
> I've changed the name of the class in the descriptor file for example,
> but the name remains the same.
>
> > Once you know the pattern, you will probably get to the point where
> > you don't need wsdl2java and can create the capability classes
> > yourself, and add the configuration to muse.xml:)
>
> Do you means we should write our own wsdl2java (actually we've modified
> it already a lot) to parse the WSDLs and to generate appropriate classes
> with reasonable names?
>
> Regards, Alex
>
> > -----Original Message-----
> > From: Alexander Willner [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, September 02, 2007 12:26 PM
> > To: [email protected]
> > Subject: Re: WSDL2Java, Capabilities - Newbie
> >
> > Hi Nelson,
> >
> >> I would like to know if it's a default behavior that when I run
> >> wsdl2java, it always generate IMyCapability.java and
> >> MyCapability.java
> >
> > yes I think it is the default behavior.
> >
> >> When I run wsdl2java -j2ee axis2 -wsdl SimpleResource.wsdl, it
> >> generates the correct directories, but still java files are
> >> IMyCapability.java and MyCapability.java.
> >
> > I think you should use "-descriptor FILE The Muse descriptor to
> > use" but anyway we were not able to change to name of the MyCapability
>
> > and MyService class. Have you found a solution already?
> >
> > Regards, Alex
> >
> > Am 31.08.2007 um 00:51 schrieb Nelson Kotowski:
> >> Hi everyone,
> >>
> >> How're you doing?
> >>
> >> I'm working on Muse Tutorial and i would like to know if it's a
> >> default behavior that when i run wsdl2java, it always generate
> >> IMyCapability.javaand MyCapability.java , with such names, and how to
> >> proceed if i want to change it. I mean, in the samples directory
> >> (eg.,
> >
> >> \muse- 2.2.0-bin\samples\j2ee\simple\src\org\apache\muse\test\simple
> >> \second) there
> >> are pairs of capabilities files, but their names are strictly related
>
> >> to the each operation defined. How come that happened :) ? Was it a
> >> simple rename file operation? :)
> >>
> >>
> >>
> >> Another thing: When you define the Capability concept, in the
> >> Programming Model, do you mean that one capability stand for an
> >> entire
> >
> >> Java Class? Or does a capability stand for methods that a Java Class
> >> provides (i mean, a java class with 10 methods would be said to have
> >> 10 capabilities?)?
> >>
> >> Best regards,
> >> Nelson Kotowski.
>
>
>
> ---------------------------------------------------------------------
> 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]
>
>
