October 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Identity] - Re: JBoss Identity Design Preview

by bdaw

Makes sense. I'll refactor the API/SPI accordingly later then. At the moment I want to add configuration and bootstrapping mechanism so the framework can be tried out easier. It should also enable us to improve testsuite and let apply proper refactorings easier. Lets collect all the ideas now :) "jeff.yuchang" wrote : "bdaw" wrote : | | .... | | | | when I referred to extension, I was thinking about we might want to oder by some other attributes. not just name. | | The above approach seems better to me, as you said, it would be easy for us to discover the supported features then 'Parameter Object' way. | | -Jeff View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184746#4184746 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184746

15 years, 7 months

1
0
0 / 0

[Design of JBoss Identity] - Re: JBoss Identity Design Preview

by bdaw

This is something I was thinking about from the beginning. It can be done by keeping reference to the session in identity model classes. The main problem I see is the mix of two approaches: - most management methods in the model objects (Identity/Group/Role) - all management methods in manager objects connected to the session (the only reason to have 4 separate managers is to not end up with 100 methods in IdentitySession) Now to mix - some methods in Identity/Group/Role and some in managers Most of the search/find/resolve methods need to remain in managers anyway. Now if you think about the assignments you can place methods you mentioned in the Identity/Group but those operating on the collections will need to remain in the managers: public void associateGroups(Collection<Group> parents, Collection<Group> members) throws IdentityException Also you can have group.findAssociatedGroups(GroupType groupType, boolean parent, boolean inherited, ... ) but then you still need to keep few of findXXX methods in the manager as they don't belong to one model object... What I'm afraid of is the confusion of users where to look for certain methods. That's why I decided to put all all methods in the managers. I'm not totally against the approach you suggested but I'm simply not sure if it can be done without making API a bit messy. We can discuss about possible solutions. One idea would be to simply duplicate some methods to have them in both places. "jeff.yuchang" wrote : Firstly, I think the API and SPI is very good. It is very flexible. ;-). | | However, I had a thought when I saw the OrganizationTest class. | | | session.getRelationshipManager().associateGroups(rhOrg, jbossDivision); | | session.getRelationshipManager().associateGroups(rhOrg, rhelDivision); | | | | I was thinking it would be easier to see the relationship if we do as following in the API level. | | | | rhOrg.addGroup(jbossDivision); | | rhOrg.addGroup(rhelDivision); | | | | I know the latter one might add complexity in the implementation. But it seems to me more clearer from the API perspective. I don't know which way to better to go. Just bring about this thought, see what you guys are thinking of this. | | Thanks | Jeff View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184745#4184745 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184745

15 years, 7 months

1
0
0 / 0

[Design of JBoss Identity] - Re: JBoss Identity Design Preview

by jeff.yuchang

"bdaw" wrote : I was thinking about using something similar to JNDI SearchControl mechanism. Then offset/limit and orderByName/ascending could be placed in two separate objects passed in an array. | | | | Collection<Identity> findAssociatedIdentities(Group group, boolean inherited) throws IdentityException; | | | | Collection<Identity> findAssociatedIdentities(Group group, boolean inherited, IdentitySearchControl[] isc) throws IdentityException; | | | | One benefit is to let add other parameters in the future, the other is easy discovery of supported features (is specific control supported). | | What kind of extensions do you have in mind btw? | | when I referred to extension, I was thinking about we might want to oder by some other attributes. not just name. The above approach seems better to me, as you said, it would be easy for us to discover the supported features then 'Parameter Object' way. -Jeff View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184744#4184744 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184744

15 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Expression Evaluation in ActionHandler Properties

by tom.baeyens＠jboss.com

i also think that we should address improvements of el usage in jpdl 4 only View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184743#4184743 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184743

15 years, 7 months

1
0
0 / 0

[Design of JBoss Identity] - Re: JBoss Identity Design Preview

by bdaw

I was thinking about using something similar to JNDI SearchControl mechanism. Then offset/limit and orderByName/ascending could be placed in two separate objects passed in an array. | Collection<Identity> findAssociatedIdentities(Group group, boolean inherited) throws IdentityException; | | Collection<Identity> findAssociatedIdentities(Group group, boolean inherited, IdentitySearchControl[] isc) throws IdentityException; | One benefit is to let add other parameters in the future, the other is easy discovery of supported features (is specific control supported). What kind of extensions do you have in mind btw? "jeff.yuchang" wrote : Hi, | | One thought for the API: | | Collection findAssociatedIdentities(Group group, | boolean inherited, | int offset, int limit, | boolean orderedByName, | boolean ascending) throws IdentityException; | | For this API, can we wrap the offset, limit, orderedByName, ascending into a parameter Object, so that it other project might be easier to extend this class meet some other projects needs. | | I also noticed that the other methods, such as findAssociatedGroups(....). | | Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184741#4184741 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184741

15 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Ordering Group -- Transaction Scenario Analysis (Typical

by timfox

Howard - don't get too hung up on your code. :) First I would like us to discuss how the current grouping approach (from JBM 2.0) does or does not solve the problem, and what changes would need to be made to that code to get it to work. This includes the MDB case. Once we've worked out how to solve the problem, we can think about what actual code to use, and write tests BTW I'm not sure what you meant by "change it to handle priorities" View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184735#4184735 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184735

15 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Passivating EJB 3 Stateful Session Beans stops the World

by ALRubinger

"ALRubinger" wrote : https://jira.jboss.org/jira/browse/EJBTHREE-1549 I've committed tests and a fix for this issue. r80096 will show that instead of holding the cacheMap's intrinsic lock throughout passivation, we now just make a copy of the Map's contents, then free the lock before running passivation. Side effect: Perhaps removal task might sneak in there and remove an instance before passivation can come along. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184734#4184734 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184734

15 years, 7 months

1
0
0 / 0

[Design of JBoss Identity] - Re: JBoss Identity Design Preview

by jeff.yuchang

Firstly, I think the API and SPI is very good. It is very flexible. ;-). However, I had a thought when I saw the OrganizationTest class. | session.getRelationshipManager().associateGroups(rhOrg, jbossDivision); | session.getRelationshipManager().associateGroups(rhOrg, rhelDivision); | I was thinking it would be easier to see the relationship if we do as following in the API level. | rhOrg.addGroup(jbossDivision); | rhOrg.addGroup(rhelDivision); | I know the latter one might add complexity in the implementation. But it seems to me more clearer from the API perspective. I don't know which way to better to go. Just bring about this thought, see what you guys are thinking of this. Thanks Jeff View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184729#4184729 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184729

15 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Some Issues for Community

by jaikiran

Okay, i will start work on this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184721#4184721 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184721

15 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Ordering Group -- Transaction Scenario Analysis (Typical

by gaohoward

Yes, my code is almost there and what I need next is tests. The grouping approach should work but I still need to change it to handle priorities, or multiple MDB cases for example. Once I put some changes in grouping code, it's polluted and still need tests. So I'd rather keep my code and writing tests now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184713#4184713 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184713

15 years, 7 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 October 2008