Hi,
I disagree,
What is the point of moving classes from org.apache.wsif.wsdl to "make
room" for the WSDL2Java tools. The tool is new, and should be put somewhere
else if it does not make sense to have it alongside the other
org.apache.wsif.wsdl classes, rather than move existing classes.
Also, I disagree that the classes are not WSIF-specific. The WSDLLocators
aren't WSIF specific but the other classes are. The factory is WSIF
specific. It uses the pluggable providers functionality to make sure that
wsdl extensions used by the providers are registered with the WSDLReader.
This is a runtime WSIF specific bit of code that makes no sense to any
other project. The wsdl extensions are WSIF specific, no other project uses
them without WSIF. If other projects do want to use the extensions they can
already, they just need to prereq WSIF.
I vote for putting the WSDL2Java WSIF class in org.apache.wsif.tools and to
leave org.apache.wsif.wsdl alone.
Owen
|---------+---------------------------->
| | Nirmal |
| | Mukhi/Watson/IBM@|
| | IBMUS |
| | |
| | 14/03/2003 15:56 |
| | Please respond to|
| | wsif-dev |
| | |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: WSIF WSDL2Java
|
|
|
|
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Hi,
I think all of what is now in org.apache.wsif.wsdl should be under
org.apache.wsdl. The WSDL extensions, factory impl that populates the
extensions registry and loctor impls all aren't WSIF-specific. Putting them
under org.apache.wsdl would make it simpler for other projects to take
advantage of these WSDL extensions.
That would leave org.apache.wsif.wsdl free for WSIF's additions to
WSDL2Java, Java2WSDL etc.
Nirmal.
"Anthony Elder" <[EMAIL PROTECTED]>
To:
[EMAIL PROTECTED]
03/14/2003 10:40 AM cc:
Please respond to wsif-dev Subject: Re:
WSIF WSDL2Java
Hmm, I think you'll need to discuss (1) and (2) on axis-dev, thats not
something I can do much about without them agreeing, and it wouldn't be
till post AXIS 1.1 I expect. (3) and (4) is what we have today already.
For (4) I was asking if org.apache.wsif.tools.WSDL2Java may be better than
org.apache.wsif.wsdl.WSDL2Java? See Owen's post 2nd from bottom below.
( and org.apache.wsif.tools.WSDL2WSDL and org.apache.wsif.tools.Java2WSDL)
...ant
Anthony Elder
[EMAIL PROTECTED]
Web Services Development
IBM UK Laboratories, Hursley Park
(+44) 01962 818320, x248320, MP208.
"Sanjiva Weerawarana" <[EMAIL PROTECTED]> on 14/03/2003 13:17:38
Please respond to [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
cc:
Subject: Re: WSIF WSDL2Java
How about org.apache.wsdl.* for the (1) and (2) parts that Nirmal split.
Then org.apache.wsif.wsdl.* for (4) and org.apache.axis.wsdl.* for (3).
Sanjiva.
----- Original Message -----
From: "Anthony Elder" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 14, 2003 5:22 PM
Subject: Re: WSIF WSDL2Java
>
> So does anyone else have an opinion on the package this should be in.
> Currently its in org.apache.wsif.wsdl which is similar to AXIS. Of Owen's
> suggestions I quite like org.apache.wsif.tools, so think I'll change it
to
> that unless anyone else comments. I'd like to also add WSDL2WSDL and
> Java2WSDL utilities so it would be nice to get the package name right now
> before anyone gets use to the other name.
>
> ...ant
>
> PS, did anyone actually try it?
>
> Anthony Elder
> [EMAIL PROTECTED]
> Web Services Development
> IBM UK Laboratories, Hursley Park
> (+44) 01962 818320, x248320, MP208.
>
>
> "Paul Fremantle" <[EMAIL PROTECTED]> on 13/03/2003 09:13:52
>
> Please respond to [EMAIL PROTECTED]
>
> To: <[EMAIL PROTECTED]>
> cc:
> Subject: Re: WSIF WSDL2Java
>
>
>
>
> Nirmal
>
> I agree!
>
> We should specifically factor out the JAX-RPC neutral code. Both Axis
and
> WSIF are designed to use the JAX-RPC SEI definition, and this should be
> available independent of implementation. When we moved WSIF to use the
> SEI, the whole point was to *share* tools with JAX-RPC. So what would be
> nice is if the core code generated the interfaces neutrally, and then
> subclasses generated any implementation specific code.
>
> Paul
> ----- Original Message -----
> From: Nirmal Mukhi
> To: [EMAIL PROTECTED] ; [EMAIL PROTECTED]
> Sent: Tuesday, March 11, 2003 5:43 PM
> Subject: Re: WSIF WSDL2Java
>
>
> Hi,
>
> Just a clarification: the WSIF version of the WSDL2Java tool doesn't
> duplicate the Axis code, it overrides some methods. So what I was saying
> is that the common code should be factored out of the Axis WSDL2Java
code
> and Axis will extend it (to generate Axis stubs) and WSIF will extend it
> (to generate WSIF test cases), so we share the stub interface and java
type
> generation in a clean way.
>
> Nirmal.
>
>
>
> Nirmal
> Mukhi/Watson/IBM@ To:
> IBMUS [EMAIL PROTECTED],
> [EMAIL PROTECTED]
> 03/11/2003 12:37 cc:
> PM Subject: Re: WSIF
> Please respond to WSDL2Java
> wsif-dev
>
>
>
>
>
>
>
> Hi,
>
> WSDL tools, not related specifically to WSIF or Axis, should be shared.
> They would be of interest to any project within ws.apache.org and should
> belong to a common project, say ws-commons or something like that, IMHO.
>
> In WSDL2Java alone we have the following code, split between the Axis
> version and new WSIF version (which has some minor differences with the
> Axis one, see below):
> 1. Code to parse WSDL types, generate java classes for user-defined
types
> 2. Code to parse WSDL port type, message and generate stub interfaces
> 3. Code to generate Axis stubs and related classes
> 4. Code to generate WSIF test cases
>
> (1) and (2) belong to ws-commons. (3) belongs within Axis, (4) belongs
> within WSIF. Right now I don't have any strong preferences over where
the
> common code should go (as of today it is duplicated between Axis and
> WSIF), but eventually we should reorganize along the above lines.
>
> Nirmal.
>
>
> "Owen D Burroughs"
> <[EMAIL PROTECTED]> To:
> [EMAIL PROTECTED]
> 03/11/2003 08:42 AM cc:
> Please respond to wsif-dev Subject:
> Re: WSIF WSDL2Java
>
>
>
>
>
>
> The org.apache.wsif.wsdl package contains classes used at runtime so
> perhaps we should move the wsdl2java class to a different package. How
> about the following suggestions:
>
> org.apache.wsif.wsdl.tools
> or
> org.apache.wsif.tools
>
> If we want to keep all Axis dependant classes under the Axis provider,
> then
> we might want:
>
> org.apache.wsif.providers.soap.apacheaxis.tools
> or
> org.apache.wsif.providers.soap.apacheaxis.wsdl
>
> Just some ideas. Comments?
>
> Owen
>
>
>
> |---------+---------------------------->
> | | Anthony |
> | | Elder/UK/[EMAIL PROTECTED]|
> | | B |
> | | |
> | | 11/03/2003 12:08 |
> | | Please respond to|
> | | wsif-dev |
> | | |
> |---------+---------------------------->
> >
>
--------------------------------------------------------------------------
------------------------------------------------------------------------|
> |
> |
> | To: [EMAIL PROTECTED]
> |
> | cc:
> |
> | Subject: WSIF WSDL2Java
> |
> |
> |
> |
> >
>
--------------------------------------------------------------------------
------------------------------------------------------------------------|
>
>
>
> I've committed a hack to the AXIS WSDL2Java tool for WSIF in
> org.apache.wsif.wsdl.WSDL2Java. It changes WSDL2Java to not generate the
> classes WSIF doesn't use, so only generate the complex type classes and
> service endpoint interface, and a WSIF specific testcase The testcase
can
> use either stubs or the DII or both. For example:
>
> java org.apache.axis.wsdl.WSDL2Java -v -o\Temp -pbabel -tboth
> http://www.xmethods.net/sd/2001/BabelFishService.wsdl
>
> This makes another WSIF dependency on AXIS so maybe it shouldn't be
there
> at all? Perhaps it should be in a different package? And I'm open to
> suggestions for a better format of the generated testcase?
>
> ...ant
>
> Anthony Elder
> [EMAIL PROTECTED]
> Web Services Development
> IBM UK Laboratories, Hursley Park
> (+44) 01962 818320, x248320, MP208.
>
>
>
>
>
>
>
>
>
