RE: [Fwd: Re: axis stubs]

[David Levy <da...@thedistillery.com.au>]

Hi Chad,

Thanks for taking some interest in this, I'm glad other people have had
similar issues.

I agree that Java interfaces for the exposed business logic should drive
everything... I really hate the communication layer affecting the internal
business logic, it makes me feel really dirty working with code which
doesn't hold to this (I was recently brought in late to a project which gave
me a JAXB/base64 experience which just makes me shudder thinking about it).

Thanks for an interest, I'm glad to see that other people have had a similar
need.

The solution we're working on now is just to modify the stubs generated so
that they extend from the original interface. We've got an algorithm now for
doing this which works, and just have to put together the code which ties
the generated interface and complex type representations back to the
original interface. We could have modified the existing Wsdl2Java task to do
this, but just chose to post process the source files instead (what can I
say, I'd rather use Java regex then learn the internals of the wsdl2java
tool, though later I may have to).

Cheers,

David L

-----Original Message-----
From: Chad Woolley [mailto:lists@thewoolleyweb.com]
Sent: Monday, 21 March 2005 6:10 PM
To: davidl@thedistillery.com.au
Subject: [Fwd: Re: axis stubs]

David,

Read my post on 3-16 titled "Can Wsdl2Java make the stub implement a
specified interface?", it's related.

I think the appropriate way to do this is to generate a java interface
file which matches the generated class, and is implemented by it.  These
could then be copied and used in client or test code, without having to
make a concrete dependency on either the stub or the original class.
The generated interface name could be the original class name with an I
prepended (even though I don't like that convention), or made configurable.

I think this is a valid requirement, because I often auto-generate java
stubs for use in my test code, but use the original beans in that same
test code, thus encountering the namespace conflicts you describe (same
class, different packages).  Also, if you have client code which depends
on the stubs, it is cleaner and more testable to be able to make it
depend on an interface rather than a concrete class.

FYI, I also have automated code in my build script (Maven) which can
automatically build a war from the current project, deploy it, and
invoke Wsdl2Java (with a couple of hacks) to automatically generate the
stubs.  You can also run it against an external war or deployed war.
This is really nice if you want to use the stubs during testing, or
automatically keep the stubs up-to-date with the wsdl.

I'd dig in and try to do this if I had more time or perhaps if an axis
dev showed interest in this.

Thanks,
Chad Woolley
**



The Distillery Pty Limited
ABN 69 080 932 467
PO Box 940, Dickson ACT 2602, AUSTRALIA
Phone: +61 2 6272 0200
Fax: +61 2 6262 5151
Web: www.thedistillery.com.au

The Distillery Inc
2111 Wilson Blvd, Suite 700,
Arlington, Virginia 22201, USA
Phone: +1 703 351 5082
Web: www.thedistilleryinc.com

The Distillery (Europe) Ltd
53 Chandos Place London WC2N 4HS
Tel: +44 (0)20 7812 6692
Fax: +44 (0)20 7812 6677


---------------------------------------------------------------------
The information contained in this email and any files attached may be
confidential and/or copyrighted information of The Distillery, Third
Parties and/or the intended recipient and may be the subject of legal
privilege or public interest immunity. You may only reproduce or
distribute the material if you are expressly authorised by us to do
so. If you are not the intended recipient, any use, disclosure,
copying, circulation, forwarding, printing or publication of this
message or attached files is strictly forbidden.

If you have received this document in error or are not an intended
recipient, please notify the sender and delete from your Inbox and/or
system.

The Distillery does not represent or warrant that files attached to
this e-mail are free from computer viruses or other defects and
liability is limited to the resupply (or cost of resupply) of the
attached files.
---------------------------------------------------------------------