[Design of JBoss Portal] - Re: LDAP Support expectations
by bvogt
"bdaw" wrote :
| Any contribution is kindly welcome. If you are willing to help you need to
| 1) sign contributiors agreement: http://labs.jboss.com/portal/con?noproject=true
It's on the way...
"bdaw" wrote :
| 4) And if you contribute more often and gain trust of the team you can get svn access in the future ;)
we will see...
For now, can you please give me an understanding of the MembershipModule?
- where is, e.g., getName() ?
- I can see: assignRoles(User user, Set roles)
does this mean, that all roles are only assigned to the user?
Let's imagine a "dynamic role assignment" feature with:
- assignRoles(Group group, Set roles), which adds roles to a group
- assignUser(Group group, Set users), which adds members to a group
and the IdentityLoginModule evaluates the group memberships of the
user, which is logging in, and assigns all roles of all groups found.
This would reduce the management effort if, e.g. one role (i.e. portal functionality) shall be removed from a whole group of users.
What do you think about it?
Burkhard
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983000#3983000
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983000
18 years, 2 months
RE: [jboss-dev-forums] [Design of JBossCache] - Re: JBC and RPC
by Brian Stansberry
I agree w/ this, although I think it's a shame not to make JBC somewhat
more extensible in this area. Extensible in the sense of being able to
add new types of JBCMethodCall. (Maybe people can; my impression from a
couple months back is you can't.) Extensible for the purpose of adding
new/improved caching behavior, e.g. acquire a lock around the cluster or
something. May be a bad example. But if people can add a new
JBCMethodCall, they can add new functionality, which may get contributed
back to the core project. Right now this is very difficult to do.
Solving this kind of problem is not trivial either, since the
interceptor behavior is tightly bound to the type of method call. But
it's something to think about -- someday when we all have free time....
For generic RPC functionality, unrelated to core caching functions, I
think the way to go is to use two channels with a multiplexer.
jboss-dev-forums-bounces(a)lists.jboss.org wrote:
> I still don't think JBC is the place for a generic RPC
> library. Thats what JGroups RpcDispatcher is there for.
>
> View the original post :
> http://www.jboss.com/index.html?module=bb&op=viewtopic&p=39829
> 35#3982935
>
> Reply to the post :
> http://www.jboss.com/index.html?module=bb&op=posting&mode=repl
> y&p=3982935 _______________________________________________
> jboss-dev-forums mailing list
> jboss-dev-forums(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-dev-forums
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
18 years, 2 months
[Design of JBoss jBPM] - enterprise services ready
by tom.baeyens@jboss.com
finally the enterprise based services are ready in HEAD. The enterprise subproject produces an .ear file with the following configurations:
* the messaging service is now based on JMS/MDB
* the scheduler is based on ejb timer service
* all transactions are based on CMT
There is also a test setup that makes use of cactus. To run the tests, proceed as follows:
1) in build, do ant get.dependencies
2) in jboss/configuration do ant install.jboss.and.configure.jbpm (CHECK YOUR ${jboss.home} AS THIS WILL OVERWRITE (incl remove) YOUR EXISTING JBOSS INSTALLATION)
3) in enterprise do ant test.and.view
Note that the enterprise subprojects (cmdlistener, cmdservice and ear) all have merged into the enterprise top level project.
The ear file should be self contained except for the hibernate libraries. I think i'm going to reference the hibernate libs in the manifest Class-Path entries already so that merely adding those dependent libs to the ear file could make it self contained on any app server.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982985#3982985
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982985
18 years, 2 months
[Design of JBossCache] - JBC partial state transfer and Region.activate()
by vblagojevic@jboss.com
Hey guys,
I spent previous two days investigating new JGroups callback based partial state transfer implemented in JBC HEAD. Previous JBC releases relied on RPC based mechanism to implement partial state transfer. We are trying to move partial state transfer to JGroups API. The main reason why we want to do this is to harness benefits of FLUSH protocol from JGroups. I have a working version that is elegant and does not require a lot of coding. However, I have discovered that concurrent activation test is not always passing.
Concurrent activation test starts N cache nodes and each node concurrently activates certain region. Underneath, for each activate requests the plumbing does partial getState with flush. In order to have this work reliably I have to implement a feature in FLUSH [1] that supports concurrent flushing. Bela and I talked about this problem on our conference call and he gave me some ideas how to do this a ala concurrent jgroups merge.
This task seems like a priority for jbc 2.0. What should I do in terms of JBC release plan? I can have partial state transfer implemented soon but as I mentioned above concurrent activations will not work reliably until [1] is resolved. Bela has agree that we will include this feature/fix in JGroups 2.4 service pack but delivery date of for this SP is very undetermined. My estimate is that coding and testing [1] along with testing of partial state transfer and concurrent activation in JBC will take around 3 weeks.
Regards,
Vladimir
[1] http://jira.jboss.com/jira/browse/JGRP-332
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982982#3982982
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3982982
18 years, 2 months