The separation of the dispatcher and the result dispatcher is an XWork
enhancement. The old Client dispatcher relied on the same servlet receiving
the request, running the Action, and returning the serialized result. Now
the first servlet ends with the pass to proxy.execute() and xwork.xml causes
the result dispatcher to take over at the correct time.
Logging is commons-logging.
Automatic IO retries mean that if there is an IOException when communicating
with the remote servlet, it will retry up to a specified number of times. It
will also pause between each retry. These parameters are expressed in the
properties file passed at connection factory creation time. The key benefit
of this is that retries can be shielded from the business logic.
Properties based configuration was chosen to make it easier to add or
enhance connection factories. It allows connection factories to implement an
interface, rather than be classes with many property setters. The interface
based approach to connection factories also allows runtime selection of the
implementation to use, so for example corporate users might use the
HTTP/HTTPS factory (firewall friendly), whilst home users might choose an
RMI factory (when built).
Here is some code that starts the HTTP/HTTPS factory and sends the action
over an HTTPS connection that accepts any server certificate.
Properties props = new Properties();
props.setProperty("url", "https://localhost:8443/admin/ClientDispatcher";);
props.setProperty("trustManager",
"com.fremerx.webwork.dispatcher.ClientActionFactoryHttpTrustAny");
//props.setProperty("trustManager",
"com.fremerx.webwork.dispatcher.ClientActionFactoryHttpTrustKeystore");
//props.setProperty("keystoreFile", "c:/dev/keystore.rootca");
//props.setProperty("keystorePassword", "mypassword");
ClientActionFactory caf = new ClientActionFactoryHttp(props);
TestAction testAction = (TestAction) caf.createClientActionProxy(new
TestAction());
//testAction.getClientActionInvocation().setRemoteActionName("ThisDifferentA
ction");
testAction.setParam1("foo");
String result = testAction.execute(); // result code as per normal WW
TestAction resultObject = (TestAction)
testAction.getClientActionInvocation().getResultAction(); // result object
The factory's createClientActionProxy method returns a local proxy enabled
object. This object has interceptors on its setXXX methods and execute. In
the Client dispatcher we don't serialize this client side proxy object.
Instead we send a map of its property sets to the servlet, along with the
name of the target action. The setRemoteActionName method expresses which
action you want run on the remote server. By default the connection factory
sets it to be the same name as the proxy object created on the client. This
allows you to have lightweight objects on the client if you prefer, rather
than the full actions.
In relation to HTTPS, the setProperty for "trustManager" expresses which
pluggable trust manager you wanted to use. A trust manager is just a class
that implements a given Client dispatcher interface, with that interface
allowing the class to receive a copy of the connection factory properties
and return to the connection factory a SSLSocketFactory. As shown above, the
Client dispatcher includes two such classes: one that accepts any server
certificate (useful for self-signed certificates or where server identity
assurance isn't required) and another that accepts any server certificate
provided it is in the identified local keystore. Certificates signed by
Verisign, Thawte etc are accepted by default if you don't express a
"trustManager". Being an interface that hooks into the HTTP/HTTPS connection
factory, developers with advanced needs not accommodated by these three
alternatives can create their own customised SSLSocketFactory objects.
As mentioned, I am currently working on a notification model so the client
GUI can display send/receive/retry progress. When that is ready, I'll post a
patch to Jira so the community can take a look.
----- Original Message -----
From: "Francisco Hernandez" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 18, 2003 2:19 PM
Subject: Re: [OS-webwork] Re: Webwork in Swing Application?
> you mentioned adding HTTPS support..
>
> does the current webwork2 implementation not support HTTPS?
>
> also could you describe what some of these enhanced features do like
> pluggable HTTPS certificate acceptance
> classes, logging, Properties-based configuration, automatic IO failure
> retries, separate dispatcher and result servlets?
>
>
> ----- Original Message -----
> From: "Christoph Kiehl" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, July 17, 2003 3:50 PM
> Subject: [OS-webwork] Re: Webwork in Swing Application?
>
>
> > Ben Alex wrote:
> >
> > > I've been working with Philipp Meier's WW2 Client dispatcher and have
> > > enhanced it to include things like Javadocs, pluggable connection
> > > factories, HTTPS support, pluggable HTTPS certificate acceptance
> > > classes, logging, Properties-based configuration, automatic IO
> > > failure retries, separate dispatcher and result servlets, client-side
> > > specification of destination Action via a String (ie not requiring
> > > the Action be on the client anymore - although nothing stops this)
> > > and interception of setXXX and execute methods to populate the
> > > invocation. I'm about to add a notification model so send/receive
> > > progress can be monitored by external classes (eg GUI progress
> > > indicators). I'm happy to share the code with anyone interested.
> >
> > That sounds very interesting. These are some of the features I was
> thinking
> > about. Perhaps you could post your patches somewhere? Maybe on Jira? If
> not,
> > please attach your changes to a PM.
> >
> > Thanks in advance,
> > Christoph
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: VM Ware
> > With VMware you can run multiple operating systems on a single machine.
> > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> > _______________________________________________
> > Opensymphony-webwork mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
