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.

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.