Hi Anthony,
On 5/28/06, Anthony Bigbee <[EMAIL PROTECTED]> wrote:
Hi John,
On 5/27/06, John Mettraux <[EMAIL PROTECTED]> wrote:
> Seems like this snippet
>
> ---8<---
>
> <service
> name="xmlPmapFactory"
> class="openwfe.org.engine.impl.participants.XmlParticipantMapFactory"
> >
> <param>
> <param-name>participantMapFile</param-name>
> <param-value>etc/engine/participant-map.xml</param-value>
> </param>
> </service>
>
> --->8---
>
> is missing from your etc/apre/apre-configuration.xml
I just verified that the exact same block is in my
etc/apre/apre-configuration.xml. This happens to be one .xml file I
haven't modified, so I don't think it's an encoding issue.
Strange, it works for me and it's even tested as part of the automated
test suite.
Maybe, placing the factory definition before the
CompositeParticipantMap definition would do the trick. But that
wouldn't explain why it worked for me (on linux and windows).
. Another clue is that an ls -lu (when was the
> > last time a file was accessed) of the .class file indicates it's not being
> > read/accessed every time I restart the engine and python-apre.
>
> Well, the python-apre is written in python, the equivalent of '.class'
> files for python are '.pyc'...
>
Sorry to be a little vague. I was just trying to let you know that
the python apre agent that is a service "//" executes fine, but the
java agent that is supposed to invoked as the first participant in the
workflow launched is not being accessed.
Is it linked with this participant problem ? If the apre cannot load
the participants, it won't be able to reply to the engine
("mainEngine" being a participant).
> > One specific question: Can an agent class reside in a .jar that's in
> > ./apre-scripts/ (agentPath) or do jars need to be unpacked?
>
> Agents classes must be on the agent classpath. If you want to put them
> in apre-scripts/, the jar will need to be unpacked.
Ok, sounds like a feature request is in order. For classes that
depend on third party libraries involving other .jars, unpacking all
of them might be cumbersome.
We should think about saying something like : place your java agents
jar within the apre-scripts/jars/ directory and they'll automatically
be available to the APRE.
What do you think ?
As a diagnostic technique, I did a search for all specifications of
the agent's name and found that I 2 of the 4 did match the other 2. I
corrected this and now the agent executes.
So would recommend the following (unix) technique as one potential
best practice for users to confirm accuracy and integrity of .xml
files.
$ find . -name '*.xml' | xargs egrep 'fileid-java-agent'
./etc/apre/agents.xml: name="fileid-java-agent"
./etc/worklist/passwd.xml: <principal
password="+84+10+19-102+123-96+94+50+65+84+118-49-126-36-2-49"
class="openwfe.org.auth.BasicPrincipal" name="fileid-java-agent">
./etc/worklist/worklist-configuration.xml:
<param-value>role-alpha, notif-alpha, fileid-java-agent</param-value>
./workflow-definitions/fileid_flow_1.0.xml: <participant
ref="fileid-java-agent" />
You don't need to register a principal for you "fileid-java-agent"
participant within etc/worklist/passwd.xml, principals are worklist
users, not [automatic] participants (or am I wrong : you seem to have
a store that your agent is able to read...)
I have found the third one (the association of the agent with the
store) easy to forget.
It's not necessary to have a store for an agent. The store will never
get used. And, out of the box, OpenWFE's participant map routes all
workitem for participant whose name ends with '-agent' to the java
APRE.
I still see this in engine.log:
2006-05-27 22:25:02,207 [main] WARN
openwfe.org.engine.impl.participants.CompositeParticipantMap -
lookupFactories() no ParticipantMapFactory named 'xmlPmapFactory'
found.
But now I only see it once (at startup).
OK, that's great, it means that at startup it doesn't find the
factory, as its the service that gets initialized next. By placing the
factory configuration before the pmap service itself, you won't have
this message anymore.
And the minor warning 'lookup() didn't find an env at ...' persists in
engine.log, but I am no longer concerned about it given your
explanation and its planned disappareance in a future release.
Fine, I still have to find time to devote to eradicating it. Probably
two lines interverted somewhere in my code.
Thanks for all the feedback to date, I'm getting very close to a
functioning prototype.
That's good to hear.
Have a nice evening,
--
John Mettraux -///- http://jmettraux.openwfe.org
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid7521&bid$8729&dat1642
_______________________________________________
OpenWFE - Open source WorkFlow Engine
OpenWFE-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openwfe-users
