Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Workflow CPAN distribution.

Report information
The Basics
Id: 18159
Status: resolved
Priority: 0/
Queue: Workflow

People
Owner: jonasbn [...] cpan.org
Requestors: andrewo [...] oriel.com.au
Cc: alech [...] cpan.org
AdminCc:

Bug Information
Severity: Important
Broken in: 0.17
Fixed in: 1.34_3



Subject: Workflow::Factory subclassing not supported?
Subclassing Workflow::Factory just plain doesn't work, unless I'm missing the main thrust of the idea :) Please let me know what obvious thing I'm missing here (after spending a few hours looking at it I'm sure I must be missing something!) The two attached files demonstrate the problem when used with the ticket example. Place Factory.pm in the App subdir and then run subclass_test.pl in the root. subclass_test.pl is basically just a drastically cut down ticket.pl Detail: When you use a custom factory class in your app and call FACTORY->add_config_from_file() it initialises structures in $Workflow::Factory::INSTANCES{$custom_class}. Cool, no problem. Until the core code, eg Workflow::State, does a "use Workflow::Factory qw(FACTORY);" which causes all the local-to-Workflow::State FACTORY function accesses to look for configs in the 'Workflow::Factory' hash entry (which is empty) rather than the $custom_class entry. So things die. Obviously there are several ways around this: 1. Use $custom_class->instance->new_method and Workflow::Factory->instance->for_everything_else() in your code but that sorta defeats the purpose of subclassing. 2. Add custom functions directly into Workflow::Factory 3. Not actually subclass in $custom_class but instead act as a proxy for all methods and actually call Workflow::Factory->some_method for everything in, eg, an AUTOLOAD situation. Not nice. 4. What am I missing? :) All I'm attempting to do is to override methods like create_workflow() and fetch_workflow() so that I can dynamically load workflows at runtime rather than have to preload a large set of XML on startup.
Subject: Factory.pm
package App::Factory; use strict; use base qw(Workflow::Factory); sub some_cool_method { print shift,": Wheee\n"; } 1;
Subject: subclass_test.pl
#!/usr/bin/perl use strict; use Log::Log4perl qw( get_logger ); use App::Factory qw( FACTORY ); $| = 1; Log::Log4perl::init( 'log4perl.conf' ); my $log = get_logger(); $log->info( "Starting: ", scalar( localtime ) ); FACTORY->add_config_from_file( workflow => 'workflow.xml', action => 'workflow_action.xml', validator => 'workflow_validator.xml', condition => 'workflow_condition.xml', persister => 'workflow_persister.xml' ); $log->info( "Finished configuring workflow factory" ); exit;
From: alech [...] cpan.org
On Tue Mar 14 03:31:14 2006, guest wrote: Show quoted text
> Subclassing Workflow::Factory just plain doesn't work, unless I'm > missing the main thrust of the idea :) Please let me know what obvious > thing I'm missing here (after spending a few hours looking at it I'm > sure I must be missing something!)
I believe you are not missing it, unfortunately. Subclassing Workflow::Factory seems to be broken. Show quoted text
> $Workflow::Factory::INSTANCES{$custom_class}. Cool, no problem. Until > the core code, eg Workflow::State, does a "use Workflow::Factory > qw(FACTORY);" which causes all the local-to-Workflow::State FACTORY > function accesses to look for configs in the 'Workflow::Factory' hash > entry (which is empty) rather than the $custom_class entry. So things die. > > Obviously there are several ways around this:
[...] 5. Hacking the symbol table. Not exactly the nicest way, but it is quick and easy. my $workflow_factory = OpenXPKI::Workflow::Factory->instance(); local *Workflow::State::FACTORY = sub { return $workflow_factory }; before adding the config does the trick for us. At least for the creation. Before actually using it, we need to do this (without the local, unfortunately) for Workflow::State, Workflow::Action, Workflow::Factory, Workflow and our custom observer. Show quoted text
> All I'm attempting to do is to override methods like create_workflow() > and fetch_workflow() so that I can dynamically load workflows at runtime > rather than have to preload a large set of XML on startup.
Why would you need to override them? Isn't having a workflow factory that has already been initialized with the config enough? This is how we deal with it at the OpenXPKI project. Best regards, Alex
In the release: 1.34_3 this particular issue is addressed in a new patch. Checked up on the issue and got the following response from Martin Bartosch: ### The comment Alex wrote on this ticket was referring to exactly the same problem which Oli has solved with his contribution. With this patch we were able to get rid of a very nasty code ("hacking the symbol table, again...") fragment in the workflow API of OpenXPKI. So from the perspective of OpenXPKI this issue can be closed as fixed now. Including this patch was immensely helpful for us - thanks a lot for accepting Olis submission! ### We are closing the issue for now.