"kukeltje" wrote : Did any of you guys look at the examples/testcases docs etc...?
|
| Tip: create an action that takes parameters from the definition and on creation of an instance stores this definition data in the instance... it's so simple. just experiment a little.
i dont think its a good idea for each process instance to keep a variable which would never changed since the definition beening deployed....
but i think i find a way ,that is the 'description' field ,though it is not refered in neither docs nor examples....
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982569#3982569
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982569
Oops! Sorry, RPCManager doesn't do what you need to do. As a matter of fact, with JGroups 2.3 multiplexer, you could have created a multiplexer stack and create your own RPCManager and then have both RPCManager and Cache to share the same channel. However, this process is not straightforward for standalone. I will raise an issue to discuss.
Meanwhile, if don't mind to use separate channel, you can look into org.jboss.cache.rpc.RPCTreeCache. Basically, you can create a separate RPCTreeCache instance (a la TreeCache 1.4 style) and execute your RPC calls there.
Keep in mind the class is deprecated though.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982559#3982559
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982559
You actually bring up a good point about not wanting to use JAAS.
Although I recommend JAAS for obvious benefits (standard, identity propagation through various layers in the container etc)
if some light weigh app wants to do custom login behavior, maybe there might be value in creating a contract very much like the IdentityManager that will let custom login usecases do what they do, but still keep token management inside the valves in the framework.
The key is to figure out what the contract between the framework and the custom login behavior will be....
thinking along the lines of what objects need to be created and place in what scope (request,session) etc
I will have to think about this one ;)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982558#3982558
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982558