Tim: Without looking into it too deeply (and without knowing anything about Workflow), I can say the easiest thing from the sslext side is to redefine SecureActionConfig to extend WorkflowMapping, just as you say. If you have problems, I can look at it more.
Steve > > From: Tim Shadel <[EMAIL PROTECTED]> > Date: 2003/10/16 Thu PM 01:52:22 CDT > To: Struts Users Mailing List <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED] > Subject: Re: SSLExt and Struts Workflow? > > I know this thread is a couple weeks old, but I just started looking > into this myself. > > Actually, I don't think that they are currently compatible, but not > because of the RequestProcessor. Matthias has made it easier to write a > RequestProcessor that includes others, so that should be possible > (though I haven't done it). The problem seems to be that they each > require a custom ActionMappings class: > > <action-mappings type="org.apache.struts.config.SecureActionConfig"> > > <action-mappings type="com.livinglogic.struts.workflow.WorkflowMapping"> > > I assume that you can't use both. After looking at the code, it appears > that it may not be hard to change SSLExt to expect an Interface instead > of a class in most areas that the SecureActionConfig is really needed > for the config.getSecure() call (WorkflowMapping seems to hold more than > simple get/set methods). It seems that the changes to > SecureActionConfig are most in the checkSsl() and computerUrl() methods. > I may be missing something, but it doesn't seem like much would break. > > Eclpse's "Extract Interface..." refactoring can't do it automatically, > but gives a quick glance at the areas most affected. If the SslExt code > could use an interface, then it would be possible to extend the > WorkflowMapping, add the needed methods, use the new class in the > <action-mapping> and then use both SslExt and Struts Workflow together. > > Steve and Matthias, do you see any glitches with this approach? If not, > I may try to start working at it (isn't that the general rule - don't > propose something unless you want to volunteer to help? :-D). > > Thanks for your great extentions to Struts! > > Tim > > Matthias Bauer wrote: > > If you > > still want to use the sslext RequestProcessor you should be easily able > > to do that: It is fairly trivial to build an > > SSLExtWorkflowRequestProcessor in just the same way as the > > TilesWorkflowRequestProcesser is built, which is included in the Struts > > Workflow Extension. This is because all the workflow logic is extracted > > into a separate class WorkflowRequestProcessorLogic. If you are > > interested, have a look at the classes WorkflowRequestProcessor, > > TilesWorkflowRequestProcessor, WorkflowRequestProcessorLogic and > > WorkflowRequestProcessorLogicAdapter. > > > > --- Matthias > > > > > > Steve Ditlinger wrote: > > > >> I'll admit to not having used Struts Workflow. But I don't know of any > >> reason why sslext should not work, as long as actions are defined in a > >> struts config file like other struts apps. > >> > >> If Struts Workflow uses its own RequestProcessor, you would not be > >> able to > >> use the sslext RequestProcessor (without creating your own custom > >> RequestProcessor). However, that is OK. You can use the sslext Plugin > >> without the sslext RequestProcessor. Assuming the use of the sslext > >> tags, > >> the sslext RequestProcessor is really only needed as a failsafe for > >> redirecting to the correct protocol if a URL is improperly hand-entered. > >> > >> HTH, > >> Steve > >> > >> > >> ----- Original Message ----- From: "Mick Knutson" > >> <[EMAIL PROTECTED]> > >> To: "struts" <[EMAIL PROTECTED]> > >> Sent: Tuesday, September 23, 2003 2:54 PM > >> Subject: SSLExt and Struts Workflow? > >> > >> > >> > >> > >>> Does SSLExt and Struts Workflow work together? > >>> > >>> --- > >>> Thanks > >>> Mick Knutson > >>> http://www.baselogic.com > >>> --- > >>> > >>> --------------------------------------------------------------------- > >>> 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] > >> > >> > >> > > > > > > </div> > > > > > > --------------------------------------------------------------------- > 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]
