Hi,
Re. WSIF WSDLFactory I wasn't aware of the WSIF-specific nature, so of course it should stay where it is.
Re. the other code you're right, we shoud leave things where they are and deprecate the classes if/when they are in a common project.
Re. org.apache.wsif.wsdl as the package for WSIF's WSDL tools: that seemed natural to me since org.apache.axis.wsdl already has Axis' WSDL2Java, Java2WSDL etc. (and org.apache.wsdl would similarly be a natural name for common WSDL tools/classes). However org.apache.wsif.tools sounds fine if the majority thinks so.
Thanks,
Nirmal.
| "Owen D Burroughs" <[EMAIL PROTECTED]>
03/14/2003 01:17 PM
|
To: [EMAIL PROTECTED] cc: Subject: Re: WSIF WSDL2Java |
Hi Nirmal,
I can see where you are coming from but I still disagree with some of the
details.
I agree that having a factory that makes sure the extensions are registered
with the WSDLReader would be very useful if the extensions are supported in
a common project but the WSIF WSDLFactory is not it since it *is* WSIF
dependent. When WSIF providers are "loaded" at runtime, each provider can
register the extensions it requires with WSIF. The WSIFWSDLFactoryImpl then
picks up this information. It is dynamic. It relies on WSIF providers
registering their extensions...therefore it is WSIF specific. If someone
wants to write another factory that registers the java, EJB, format etc
extensions then that's fine, but the WSIFWSDLFactoryImpl does more - it
supports any extensions a custom provider wants to register.
I fail to see why the org.apache.wsif.wsdl package has to be used to put
any new classes, it seems to have come into the discussion simply because
that's where the WSDL2Java class has been *temporarily* put There is no
precedent in any other project for such a package naming scheme to be used
for wsdl tooling classes. I believe we should move the WSDL2Java class to a
new package. Then if necessary, we can to begin to enforce a new package
structure for common tooling that does not interfere with existing classes.
If other projects can take advantage of them, then supporting the java,
EJB, JMS, etc. extensions in a common project is fine, just don't
move/remove any classes from WSIF. If the extensions or other wsdl related
funtions are supported in a common project, then we can simply deprecate
the WSIF versions in favour of the common ones, thus maintaining backwards
compatibility for anyone using the existing classes.
Owen
|---------+---------------------------->
| | Nirmal |
| | Mukhi/Watson/IBM@|
| | IBMUS |
| | |
| | 14/03/2003 17:33 |
| | Please respond to|
| | wsif-dev |
| | |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: [EMAIL PROTECTED] |
| cc: |
| Subject: Re: WSIF WSDL2Java |
| |
| |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Hi,
The intent isn't to move them just to make room, that was badly put, I
believe it makes sense to do things that way.
The java, EJB, JMS, etc. extensions are all WSDL extensions, it has nothing
to do with WSIF specifically except of course that we have providers that
support them. Asking other projects to prereq WSIF just to use the WSDL
extension classes is incorrect IMO. If Axis does move to using these
bindings (instead of deployment descriptors for JMS, etc.) then it'll have
to prereq WSIF just to use these classes for example, which doesn't make
sense. It will help adoption of these WSDL bindings if they are in a common
WSDL project under Apache.
Having a factory that makes sure that the extensions are registered with
the WSDLReader would similarly be useful to any project that needs to use
those extensions, so that is not WSIF specific.
Nirmal.
"Owen D Burroughs" <[EMAIL PROTECTED]>
To:
[EMAIL PROTECTED]
03/14/2003 11:41 AM cc:
Please respond to wsif-dev Subject: Re:
WSIF WSDL2Java
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.
>
>
>
>
>
>
>
>
>
