On May 21, 2008, at 6:43 PM, Clint Gilbert wrote:
So could I generate client code directly from a class annotated with
@WebService, without
generating an intermediary WSDL? I couldn't find a way to do that
with wsgen/wsimport,
but I'd love it if that was possible.
If you have an INTERFACE (not a class) with the annotations then that
is usable for both the server side part and the client side part. No
generation required. The server implementation would implement the
interface and the @WebService annotation on it would specify the
endpointInterface. (the server impl would ONLY need the @WebService
annotation. The rest would be on the interface)
For the client side, it's just:
Service service = Service.create(serviceName);
service.addPort(portName, SOAPBinding.SOAP11HTTP_BINDING,
endpointAddress);
YourInterface port = service.getPort(portName, YourInterface.class);
Dan
Daniel Kulp wrote:
|
| One option is to go completely code first and not generate anything.
| Use the same SEI interface for the client and for the service impls.
| You don't need to generate any wsdl's or anything then. I know
Apache
| CXF supports that directly without problems. No generation of
anything
| needed at all. With the Sun RI, you would still need wsgen to
generate
| the wrapper beans/fault beans, but it can also compile them.
|
| Dan
|
|
|
| On May 21, 2008, at 1:03 PM, Clint Gilbert wrote:
|
| Jan, thank you very much for your suggestion.
|
| That was almost the first thing I tried. The problem is that my web
| service instances (I
| call them Nodes - they're components of a distributed DB system)
need
| to talk to each other.
|
| A Node needs to be compiled to generate the client bindings, and a
| Node needs to invoke
| the bindings to talk to other Nodes. There's always a circular
| dependency. I tried to
| get around this by abstracting the process of talking to a node in
| order to hide the JAXWS
| client bindings from the nodes that use them. That let me attempt
the
| two-pass
| compilation hack, but can't get around the circular dependency.
|
| I think I'm going to bootstrap my module by checking in the
generated
| code and artifacts.
|
| Just for reference, does anyone know for sure if you can give
| different configs for
| different <execution>s of maven-compiler-plugin?
|
| Jan Fredrik Wedén wrote:
| | Hi,
| |
| | Could you not split this into two modules where your step 4
resides in
| | a module which dependes on another module containing the results
from
| | 1, 2 and 3? Seems like the most correct Maven-way if you are
allowed
| | to split your codebase to accomplish this.
| |
| | On Wed, May 21, 2008 at 2:48 AM, Clint Gilbert
| | <[EMAIL PROTECTED]> wrote:
| | Hello everyone,
| |
| | First of all, I cannot overstate the beneficial effect that Maven
| has had on
| | the
| | development process at my organization. To the devs: thanks for
the
| great
| | tool!
| |
| | I have a pom that specifies two executions of the compiler
plugin, with
| | different phases
| | specified and different configs, but they're not both running.
(See
| pom
| | excerpt below.)
| | Is that expected? Can I configure multiple executions of the
compiler
| | plugin with
| | different configurations? It seems like no - [1], [2], [3] -
but I
| hope
| | someone has an
| | definitive answer.
| |
| | Here's some background on my problem, which I admit is fairly
obscure.
| | Basically, what I
| | need to do is:
| |
| | 1 Compile class A in package org.myorg, which is annotated with
| @WebService
| |
| | 2 Run JAXWS's wsgen (via maven-jaxws-plugin) to make a WSDL from
the
| | compiled A.class
| |
| | 3 Run JAXWS's wsimport (via maven-jaxws-plugin) to make client-
side
| bindings
| | from the
| | just-generated WSDL
| |
| | 4 Compile non-generated classes that reference the just-generated
| client
| | bindings. These
| | live in separate sub-packages - org.myorg.x, org.myorg.y, etc -
and
| would
| | have failed if
| | compiled during step 1 because they reference code generated in
step 3.
| |
| | I've included (what I hope are) the relevant sections of my pom
below.
| |
| | PS: Do I need to do things this way? Unfortunately, I think
so. Class
| | org.myorg.A is a
| | web service that needs to invoke other org.myorg.A web services
| arranged in
| | a tree or mesh
| | topology. I've tried to break out the bindings, the SEI (A),
and the
| | classes that
| | abstract the connection between As using the client bindings into
| | submodules, but I've
| | only managed to introduce circular dependencies.
| |
| | In the past, I've dealt with this sort of chicken-and-egg
problem by
| | generating WSDLs and
| | code and then checking them into source control. This feels bad,
| and makes
| | updates if the
| | interface of the SEI changes a hassle. I'd much rather define a
| simple SEI
| | annotated with
| | @WebService and have the low-level stuff (WSDLs, client bindings)
| generated
| | from that.
| |
| | [1]
| |
| http://weblogs.java.net/blog/ss141213/archive/2007/11/my_maven_experi.html
|
| | [2]
| |
|
http://mail-archives.apache.org/mod_mbox/maven-users/200711.mbox/[EMAIL
PROTECTED]
|
| | [3]
| |
|
http://mail-archives.apache.org/mod_mbox/maven-users/200609.mbox/[EMAIL
PROTECTED]
|
| |
| | | <plugin>
| | | <artifactId>maven-compiler-plugin</artifactId>
| | | <executions>
| | | <execution>
| | | <id>jaxws-pre-compilation-hack</id>
| | | <!-- Hack to specify order of plugin
| application -->
| | | <phase>process-sources</phase>
| | | <configuration>
| | | <source>1.5</source>
| | | <target>1.5</target>
| | | <includes>
| | |
| | <include>${source.dir}/org/myorg</include>
| | | </includes>
| | | <excludes>
| | |
| | <exclude>${source.dir}/org/myorg/x</exclude>
| | |
| | <exclude>${source.dir}/org/myorg/y</exclude>
| | | </excludes>
| | | <goals>
| | | <goal>compile</goal>
| | | </goals>
| | | </configuration>
| | | </execution>
| | | <execution>
| | | <id>normal-compilation</id>
| | | <!-- Hack to specify order of plugin
| application -->
| | | <phase>compile</phase>
| | | <configuration>
| | | <source>1.5</source>
| | | <target>1.5</target>
| | | </configuration>
| | | <goals>
| | | <goal>compile</goal>
| | | </goals>
| | | </execution>
| | | </executions>
| | | </plugin>
| | | <plugin>
| | | <groupId>org.codehaus.mojo</groupId>
| | | <artifactId>jaxws-maven-plugin</artifactId>
| | | <executions>
| | | <execution>
| | | <id>make-wsdl</id>
| | | <!-- Hack to specify order goals are run
in -->
| | | <phase>generate-resources</phase>
| | | <goals>
| | | <goal>wsgen</goal>
| | | </goals>
| | | <configuration>
| | | <sei>org.myorg.A</sei>
| | | ...
| | | </configuration>
| | | </execution>
| | | <execution>
| | | <id>make-client-bindings</id>
| | | <!-- Hack to specify order goals are run in -->
| | | <phase>process-resources</phase>
| | | <goals>
| | | <goal>wsimport</goal>
| | | </goals>
| | | <configuration>
| | | ...
| | | </configuration>
| | | </execution>
| | | </executions>
| | | ...
| | | </plugin>
| |
| |
| |
| |>
| |>
|
---------------------------------------------------------------------
| 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]
|>
| ---
| Daniel Kulp
| [EMAIL PROTECTED]
| http://www.dankulp.com/blog
|
---------------------------------------------------------------------
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFINKWrrZoE3ArapxERCBxqAKCU3L8n26Q7RljP+ne7H52BzEJtpwCgvFMA
RL+sBCrmN8/LzW8OnFeXg+I=
=9lA3
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]