Hi John, A couple of days ago I added the method to create stores at runtime. I modified WorkSession and RmiWorkSession, and it works fine. I also had to modify ApplicationContext though, because I need the path to the config file to register the store (I setted it in XmlApplicationContexBuilder). If you have a better idea to manage the config file, I could implement it. I could send you the patch if you want (when I have time to code it properly).
I have one question now, about finished workflows. I need some way to detect when a process instance finishes (to log this instance as "closed"), and reading throug the engine code, I still don't know how I could do that. I hope you can help me with this one. Thanks in advance. On 1/7/07, John Mettraux <[EMAIL PROTECTED]> wrote: > > > On 1/8/07, Gustavo Gonzalez <[EMAIL PROTECTED]> wrote: > > Hi, > > > > On 1/7/07, John Mettraux <[EMAIL PROTECTED]> wrote: > > > > > > Hi Gustavo, > > > > > > I'm pretty convinced that the strategies can fill all your > > > requirements but of course, I'm not in your boots and you're (your > > > customer is) the final judge. > > > > Maybe it's possible, but I don't see how could I give an user access to > > workitems belonging to a subset of other users. This subset of users can > > change at runtime, and I have to persist this information somehow (this > is > > the "store-level delegation" I need to do, if I make a store for each > user, > > that is). > > On the other hand, I have to give access to the workitems corresponding > to > > the groups the user > > belongs to, this groups can also change at runtime, but I don't persist > this > > association, I receive this list as a parameter, so what I'm doing now > is > > just to return the contents of the stores associated with the groups I > > receive. This are the things I wouldn't know how to do with the > available > > get strategies, and came up with the idea of one store per user and one > > store per group. > > and why don't you do the workitem filtering in your code ? > > > > Adding stores at runtime... maybe it would be time to separate store > > > configuration from worklist configuration. The worklist configuration > > > could include the store configuration... well... > > > Adding stores at runtime is fine, but if the worklist is restarted the > > > new stores have to be present as well. Maybe it'd be better to have a > > > totally separate store configuration file that can be overwritten > > > should any change occur. > > > > > > wdyt ? > > > > Sure, I'd have to overwrite the configuration file if a new user/group > is > > registered. Including the store configuration file in worklist > configuration > > sounds good to me, would there be a problem if we try to modify this > file > > later at runtime? (that's from inside the worklist). > > Well, I'll think about adding some way to add stores at runtime. > > > Best regards, > > -- > John Mettraux -///- http://jmettraux.openwfe.org > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
