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

[Design the new POJO MicroContainer] - Re: DependencyBuilder chain

by alesj

"kabir.khan(a)jboss.com" wrote : Can you explain the reasoning behind the chain of dependencies a bit? My knowledge pretty much stops at the AOP dependencies, which other dependencies are there? A seperate type of dependencies - AOP, injection, callback, <whatever-dependency>, ... So that there is a list or chain of DependencyBuilders to execute. I would like to plug in my @Callback/@Install/@Uninstall inspection. So, is this the way to do it - AnnotationDependencyBuilder? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041473#4041473 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041473

17 years

1
0
0 / 0

[Design of OSGi Integration] - Re: OSGi Bundle Repository

by Kevin.Conner＠jboss.com

Already fixed them! You got in before I had even committed the poms! :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041470#4041470 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041470

17 years

1
0
0 / 0

[Design of Security on JBoss] - Re: SecurityAssociation no loger valid in remote client

by anil.saldhana＠jboss.com

The current issue is an implementation/integration issue. Whoever is constructing the Invocation object on the server side has taken care of setting the principal and cred, but has not dealt with the security context. The ejb containers can ensure that there is a security context on the invocation (somebody has to do this before the security processing starts). I think I am going to stick with the explicit requirement that any invocation coming into the containers have the security context set on the invocation, by the invocation builders on the server side. In reality, we do not need the principal and the credential on the invocation because the security context would anyway contain them. There can be a chain of security interceptors right after the containers on the call path. So the security context has to be established on the server side. The client side security interceptors take care of constructing a security context and then send it on the invocation over the wire. Now if the server side invocation constructors ignore the sc that came on the wire, it is bad. I think we really need some type of Invocation construction factories that take care of such concepts. Every integration layer (ProxyFactory, BaseLocalProxyFactory, CMPFieldBrigdexxxx, WS integration layer) who are constructing the Invocation objects can use the factories. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041466#4041466 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041466

17 years

1
0
0 / 0

[Design of OSGi Integration] - Re: OSGi Bundle Repository

by alesj

Cool, great job. As you could see, I already fixed javadocs. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041463#4041463 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041463

17 years

1
0
0 / 0

[Design of OSGi Integration] - Re: OSGi Bundle Repository

by Kevin.Conner＠jboss.com

The source has been moved across and the poms updated. An update from the root is necessary to pull everything in. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041458#4041458 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041458

17 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Problem with the build?

by pgier

There are a few dependencies where the version is defined in the parent instead of in the individual modules. This way you can make sure that all the modules are using the same version of that dependency. That happened in the dependency module? It looks like it was picking up the wrong names too. For those dependencies they should be jboss-common-logging-spi and jboss-common-logging-jdk. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041441#4041441 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041441

17 years

1
0
0 / 0

[Design of Security on JBoss] - Re: SecurityAssociation no loger valid in remote client

by scott.stark＠jboss.org

In general that has to be a security aspect in the call chain to ensure a proper security context. This gets back to the cluster question you had earlier. The form of the incoming security context may need to be mapped into another form. Any existing usage of the SecurityAssociation outside of a security interceptor is broken code. Either it needs to be using a public authentication api, or it needs to be moved into a security aspect that can be kept in sync with implementation details. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041439#4041439 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041439

17 years

1
0
0 / 0

[Design of Security on JBoss] - Re: SecurityAssociation no loger valid in remote client

by anil.saldhana＠jboss.com

A discussion with thomas has brought out an issue for me. The background is that a security context can come over the wire for remote calls. Now whoever is constructing the invocation object on the server side has to be aware of this change (ie. they can set a SecurityContext on the session). Given this, the containers (session,entity) have two choices: a) Ensure that there is a security context on the invocation. b) Accommodate any integration code (that may have created their own Invocation object and forgotten to set the security context) and create the security context on the inv. This can be bad because things like runas or any tokens that may be coming over the wire may be lost. I prefer a) but may break clients. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041434#4041434 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041434

17 years

1
0
0 / 0

[Design of JBoss Admin Console] - Re: hsqldb-jdbc2-service.xml, HighMemoryMark and MaxMemoryMa

by PeterJ

This is a developer's forum, not a user's forum. Please ask your question in one of the user's forums; I suggest either Beginner's Corner or Installation, Configuration & Deployment (do not post your question in both forums!). Also, when posting XML text, surround it with [ code ] [ /code] tags (without the spaces). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041425#4041425 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041425

17 years

1
0
0 / 0

[Design of Security on JBoss] - Re: SecurityAssociation no loger valid in remote client

by anil.saldhana＠jboss.com

Additional details for http://jira.jboss.com/jira/browse/JBAS-4317 | Thomas, the security context either comes over the wire (remote calls) or comes from the thread local (Local EJB invocations). So where-ever the Invocation object is created on the server side, the security context needs to be set on the Invocation object. The IllegalStateException thrown in the containers was one way of validating that whoever was creating the Invocation object has set the security context (just the way they would have done with .setPrincipal, setCredential etc). | | The primary issue is that there are various integration layers constructing the Invocation object rather than a central place. Some of the examples where the Invocation object is created on the server side include the BaseLocalProxyFactory, ProxyFinderFactory, CMPFieldBridgexxxx. | | So I will need to revert back the IllegalStateException and need your stack trace so that I can understand where your Invocation is being created. | | Once the containers have established that the invocation does contain a security context, they set it on the thread local so that the JACC PolicyContext get Subject call always takes care of the RunAsIdentity that came into the specific container. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041418#4041418 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4041418

17 years

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 April 2007