John Mettraux wrote:
Hi Gregory,
On 1/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Right, 2 quick ones:
> - Is it possible to use a the library service with the embedded engine
> ? I've tried this:
> SimpleProcessLibrary library = new SimpleProcessLibrary();
> Map<String, String> params =
> Collections.singletonMap("url", url);
> library.init("init-foobar-library", engine.getContext(),
> params);
> engine.getContext().add(library);
> I've also tried to load it when further using the engine (because the
> url is not available at that moment) with library.load(); but 1) i'm
> not convinced I have to do that "manually", 2) it seems i end up with
> several instances of this in my store ?
You shouldn't need to use a library service with the embedded engine.
You just need to make sure to execute (launch) the processes making up
your library at embedded engine instantiation (run them before you
launch new processes that might require those library processes).
Right. I was looking for a mechanism to defer the launching of the
library, since the URL isnt available upon instanciation of the engine,
but it's easy enough to implement :)
> - Is there an equivalent to the audit trail, is it useable w/ the
> embedded engine? Since it's a service, if the above was correct for the
> library, i assume I can do something similar ?
The audit trail is a worklist oriented service, unfortunately.
Ok, and since we don't have worklists with Magnolia, but rather direct
dispatches to (embedded) participants, we're stuck, is that correct ?
A little more than one month ago, Boris suggested we needed something
to replay processes, in order to rescue processes that went bad for
any reason and for migrating processes.
That'd be useful indeed.
My reply has always been : get back to the back up, but that's not
always a good solution, especially when you don't have a tight control
on the backup process.
I haven't further discussed that with Boris, he was for chatting about
it, but I prefer mailing list discussions for such technical subjects,
"Verba Volant, Scripta Manent" (may I add "Google archives"... sorry
my poor latin skills evaporated long ago).
Well, I agree with both of you; in some cases, it might be more
convenient and productive to talk/chat rather than write long emails
and potentially loose focus. After that, its maybe a matter of
informing the list about possible outcomes and getting feedback from
there :)
Anyway, the request hasn't gone totally unanswered and there is a
beginning of an implementation in OpenWFEru (rubyforge's viewsvn is
down unfortunately). Nicolas is working on it, maybe you'd like to
help us port it back to OpenWFEja. The ruby code is still young (and
lacks the 'replay' method), but it's readable and the main ideas are
easy to grasp.
It might replace advantageously the audit trail thing. We could even
store the new 'journal' in the JCR.
Sounds interesting, and shouldn't be to complex to implement with
augmenting our embedded participants like Nico suggested.
Thanks guys !
Of course I couldn't leave it at that, and have more: in trying to
replace calls to workSession.getHeaders, I'm trying to figure out
exactly what workitems are returned by this - I'm guessing "live" ones
? (At the moment, I'm using an xpath query on our jcr store, which I
suspect is going to return finished workflows too: //*[(@assignTo or
@participant)] ... Well, I admit I haven't digged into this yet anyway,
but to make it correct I'll need to know what getHeaders returns for
each store.
Cheers and thanks again !
g
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "OpenWFE
users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/openwfe-users?hl=en
-~----------~----~----~----~------~----~------~--~---
