January 2009 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Identity] - List of Users

by anil.saldhana＠jboss.com

Tom asks: | the actual question was: I'm trying to obtain a list of all users. | | I guess this method should do the trick: | | Collection<Identity> identities = identitySession | .getPersistenceManager() | .findIdentity((IdentitySearchControl[])null); | | I assume this gets me the users *and* groups, right ? | | I only found following search controls: | | if (control instanceof PageSearchControl) | { | pageSearchControl = (PageSearchControl)control; | } | else if (control instanceof SortByNameSearchControl) | { | sortSearchControl = (SortByNameSearchControl)control; | } | else if (control instanceof AttributeFilterSearchControl) | { | attributeFilterControl = (AttributeFilterSearchControl)control; | } | else if (control instanceof NameFilterSearchControl) | { | nameFilterSearchControl = (NameFilterSearchControl)control; | } | | Should I be looking into the attributes to filter for the users ? | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205959#4205959 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205959

15 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: BPMN in jbpm4

by koen.aers＠jboss.com

Clearly we need to discuss what we need to do to support the jPDL specific constructs in a diagram with BPMN look and feel. At the moment I see a two imminent examples of these problems: 1) Multiple outgoing sequence flow from nodes: As Bernd states in jBPM these have XOR semantics while in BPMN outgoing sequence flow in nodes have AND semantics. On the other hand, BPMN has the conditional sequence flow construct. If you think about it, the outgoing sequence flow in a jPDL state is conditional (i.e. the token is propagated along the sequence flow with the name you give when issuing the continuation signal, otherwise the default flow is chosen). Following the BPMN logic, outgoing sequence flow from jPDL nodes with XOR behaviour should have a diamond at the start and the default flow should have a transversal line. The BPMN spec does not mandate that the condition is given explicitly, so in this case the condition is implied by the implementation of the jPDL node (in this case the wait state). 2) Superstates The BPMN concept that most closely resembles superstates is the expanded subprocess. But this interferes of course with the jPDL process nodes and subprocesses. There is AFAICS no way of getting a sequence flow to connect a node with some other node inside the expanded subprocess. Any ideas here would be more than welcome. Of course other issues exist, mostly related to terminology clashes. The most obvious clashes that I can see right now are: 1) signal: in jPDL this is an event that continues the process; in BPMN it is a flare that is visible to all the processes 2) event: in jPDL this is a hook into the execution of a process, subscribers can listen to these events and perform some processing accordingly; in BPMN this is a first class citizen (a node in the diagram) that indicates e.g. the reception of a message or the raising of an exception. 3) task: in jPDL tasks are related to human tasks; in BPMN tasks are atomic activities Undoubtedly I forget a lot of other stuff, feel free to add and/or react and provide us with suggestions. I will create a wiki page where we can describe the issues that come up along with their solution. Regards, Koen View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205954#4205954 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205954

15 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: JBoss Cache Options API

by jason.greene＠jboss.com

"manik.surtani(a)jboss.com" wrote : "jason.greene(a)jboss.com" wrote : | | CacheSession session = cache.getCacheSession(); | | session.setOption(BLAH_ENUM); | | session.put(x,y); | | | | That's not a lot different from your getAdvanced(), except that the new interface allows you to set options in a separate method rather than an overloaded method. And then sticks it in a thread-local. :) | | No there is no thread local. The session object in this case would be a normal object, with fields for the current option. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205950#4205950 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205950

15 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - a method to get admin roles in RoleModule

by sviluppatorefico

what do you think about a findAdminRoles() method into org.jboss.portal.identity.RoleModule interface? Set findAdminRoles() throws IdentityException; it could avoid to write a properties file for an external portlet, so you don't duplicate roles definition in your projects. JBoss Feeds for example needs of a similar method to do authorization controls on a logged user. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205947#4205947 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205947

15 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: JBoss Cache Options API

by manik.surtani＠jboss.com

"david.lloyd(a)jboss.com" wrote : IDEA has never (iirc) had a problem with varargs. But in any case, if you do decide to go with varargs, it might be a good idea to have a varargs-less variation on the method for the no-options case (if it's common) to prevent the empty-array creation on every method invocation. Though now that I think about it, I don't remember if it makes a significant performance-wise... Not a "problem" as such, but just suggesting that you needed stuff in there. Reading off method signatures, really - the same thing that makes the javadocs misleading. Goes against the principle of varargs, IMO, since we are talking about an optional parameter, not a variable length one. At least, that is the case the way things are with a single Option object (or an EnumSet of options if options become an enum). Less ugly if we have a vararg of Options, where options are an enum and you provide as many options as you want. Not so pretty though if you are implementing an external interface, e.g. Map or javax.cache.Cache, but that does take care of the (more common) no-option use case. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205942#4205942 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205942

15 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: JBoss Cache Options API

by david.lloyd＠jboss.com

IDEA has never (iirc) had a problem with varargs. But in any case, if you do decide to go with varargs, it might be a good idea to have a varargs-less variation on the method for the no-options case (if it's common) to prevent the empty-array creation on every method invocation. Though now that I think about it, I don't remember if it makes a significant performance-wise... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205941#4205941 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205941

15 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: JBoss Cache Options API

by manik.surtani＠jboss.com

"jason.greene(a)jboss.com" wrote : | CacheSession session = cache.getCacheSession(); | session.setOption(BLAH_ENUM); | session.put(x,y); | That's not a lot different from your getAdvanced(), except that the new interface allows you to set options in a separate method rather than an overloaded method. And then sticks it in a thread-local. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205940#4205940 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205940

15 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: JBoss Cache Options API

by manik.surtani＠jboss.com

yes, I didn't quite like using varargs like that before, not just because of the way IDEs deal with it but also how it becomes misleading on javadocs, since it implies that the varargs are "necessary". That still stands, but at least it provides a cleaner approach to using thread-locals. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205939#4205939 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205939

15 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: JBoss Cache Options API

by jason.greene＠jboss.com

There is one other radical approach. Which is that you introduce a context/session for cache access that is bound to that object. Example: CacheSession session = cache.getCacheSession(); session.setOption(BLAH_ENUM); session.put(x,y); View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205933#4205933 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205933

15 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: JBoss Cache Options API

by jason.greene＠jboss.com

When we discussed varargs before, IIRC you didn't like it because of how IDEs handled it at the time. I am not sure if this has improved. Another possibility is to define a new interface which contains the overloaded methods. cache.getAdvanced() or something like that. Then you could just define a method with an overloaded EnumSet. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205929#4205929 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205929

15 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2009