February 2007 - jboss-dev-forums - Jboss List Archives

[Design of Security on JBoss] - Re: JBoss 4.2 related discussion

by scott.stark＠jboss.org

ok, good. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020901#4020901 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020901

19 years, 1 month

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Support for cross-cluster HAJNDI list operations

by scott.stark＠jboss.org

Its just because list for HAJNDI generally only has normal jndi behavior for the replicated tree. However, since we really never bind stuff into this tree, list* is not a useful method. It could be implemented to match the lookup semantics and essentially return the first context.list result from the local jndi bindings in the cluster for the context. If one really wants to see all of the bindings in a cluster, then I think we would have to return a NamingEnumeration with a NameClassPair that was a ClusteredNameClassPair to include the node in the pair. Otherwise we could go outside of the jndi api to provide this aggregate view. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020897#4020897 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020897

19 years, 1 month

1
0
0 / 0

[Design of Security on JBoss] - Re: JBoss 4.2 related discussion

by anil.saldhana＠jboss.com

There is no need to add the roles to the invocation. The principal to role mapping can be obtained via the org.jboss.metadata.AssemblyDescriptorMetaData principal to role mapping, which is available on the container passing into the interceptor. For 5.0, this is not an issue as we can use role mapping logic before authorization in the build up of the security context. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020890#4020890 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020890

19 years, 1 month

1
0
0 / 0

[Design of Security on JBoss] - Re: JBoss 4.2 related discussion

by scott.stark＠jboss.org

The PolicyContext would just be a copy even if it was not read-only. One way would be to simply add the roles to the invocation and update the authorization interceptor logic to look there in addition to the RealmMapping.doesUserHaveRole call. Not having the roles assigned to the Subject is the direction we are heading anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020885#4020885 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020885

19 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Admin content editor plugin

by julien＠jboss.com

I have finished to work on it for now. It replicates the behavior of the current same editors that have been written for JSP. It is used when creating a new window. A few remarks : - In order to be able to change the content type when creating a window, one needs to enter a window name because the validator is triggered and will fail on the empty string. This needs to be fixed either by moving the window name validation in AddWindowAction.execute() or another way that JSF offers. - The current dashboard editor needs to be redone using JSF in order to reuse the current content editors written in JSF (more powerful and reusable). This app is quite simple (one page). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020862#4020862 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020862

19 years, 1 month

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Getting rid of Subject mixin for FIELD granularity session a

by bstansberry＠jboss.com

Bit of a post to myself to document some thoughts that I'm not going to deal with right away... The prescribed jboss-aop.xml for FIELD granularity session attribute POJOs includes introduction of a Subject mixin. This is problematic, as the standard jboss-aop.xml in the PojoCache dist does not include this mixin for @PojoCacheable. Getting rid of the need for this mixin would be nice. But... Usage of the mixin: When the pojo is bound to the session, the session registers itself as an Observer. So, when the pojo is modified, the session knows it is dirty. At the end of the web request, this triggers replication of the session metadata (update version, timestamp, etc.) Benefits: 1) Session timestamp is replicated, reducing chances that the session will be timed out on another node and flushed from that node's cache. Flushing a live FIELD session is bad, as future requests for the session won't replicate the whole set of cache nodes associated with the session. So, the server where the session was flushed will likely never again have the whole set of cache nodes. There are other safeguards to ensure the timestamp is replicated (e.g. a request that occurs after > 80% of the timeout interval has gone by automatically causes the metadata to replicate. But this isn't perfect. 2) Session version is replicated. This helps in cases where sticky session enforcement is spotty, and another server thinks it is the one hosting the session. The version replication tells it it is not, and that it's locally cached copy is out of data vs. the cluster. If the user fails back over to this server, if the session version hadn't been replicated, the user will see stale data. This is a bit of an edge case, as it requires multiple failovers. Limitations and other approaches: The use of the Subject mixin doesn't work in all cases, e.g. with Collections. So, for 4.2.0 I added TreeCacheListener event handling where modifcation of nodes underneath a session's root trigger marking the session as dirty. Thus for pojo updates affecting nodes under the session root, the session will know it is dirty, making the Subject mixin unneeded. Problem is pojos will not necessarily be stored under the session root. Shared objects may be stored elsewhere. In JBC 2.0, pojos will be stored in a special internal area. For such situations, using a TreeCacheListener and trying to determine from an event Fqn what session is affected will not work. If we require that the only scope for pojo sharing is within the session, then perhaps all pojos will be stored under the session root. This would imply that in 2.0 there would be an internal area for each session. This may be a viable solution. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020846#4020846 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020846

19 years, 1 month

1
0
0 / 0

[Design of Security on JBoss] - Re: JBoss 4.2 related discussion

by anil.saldhana＠jboss.com

An issue that I did not originally think of, is the subject after authentication is read-only. Cannot do much about adding roles into the subject. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020833#4020833 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020833

19 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Re: Build System Meeting Agenda for Feb 15

by pgier

I created a new plugin called jboss-deploy-maven-plugin, and added the code here: https://svn.labs.jboss.org/labs/jbossbuild/trunk/projects/maven-plugins/j... However I'm waiting for the helpdesk to update my ssh key so I can commit the plugin to the maven repository. Once the plugin is in the repository, then I can commit the updated poms for common that will use the plugin. Should common always be built separately, or should it also be possible to build a single jar with all the classes for common? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020811#4020811 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020811

19 years, 1 month

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Support for cross-cluster HAJNDI list operations

by bstansberry＠jboss.com

HAJNDI implements the list and listBindings operations by listing what's in the replicated tree. It doesn't support creating aggregate lists of what's bound across the cluster. Is there a particular reason why that just couldn't/shouldn't be supported, at least as a configurable option? I'm sure they'd be some semantics we'd have to document clearly (e.g. what we return in the typical case where things are bound under the same name across the cluster). User wanting to federate HA-JNDI (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=102322) si what's driving this question. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020802#4020802 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020802

19 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: Simple Orchestration Quickstart

by estebanschifman

Communication between jBPM and ESB will be enabled for all transports for which there is an implemented Courier, not just JMS. Patience is a virtue View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4020793#4020793 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4020793

19 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2007