what you are saying seems pretty reasonable. Even though not having looked at SSLExt, I don't expect any more collisions than the action mapping type and the request processor. When saying that, I am assuming that SSLExt correctly copes with session tracking when switching back and forth between SSL actions and non-SSL actions. This is necessary, because the workflow state data is kept in the user's session.
If you have any questions or need some support when implementing the integration, feel free to come back to me.
--- Matthias
Tim Shadel wrote:
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]
