August 2006 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: JBAS-1841 - ServiceController/Microcontainer integration

by sacha.labourey＠jboss.com

Congrats Adrian, that's a great step! (you really need a new laptop...) ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962959#3962959 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962959

20 years

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-1841 - ServiceController/Microcontainer integration

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | Ok, That decides that. Just need a new constructor | new ServiceController(Kernel kernel) | or a setKernel() method. | In fact, all it really needs is the controller from kernel.getController() View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962958#3962958 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962958

20 years

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-1841 - ServiceController/Microcontainer integration

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | Do we want to synch up with all the current head changes and make another javaee cts branch or do this mc/vdf/profilesevice work in a branch? | That's your call. The changes I've made shouldn't affect anything. It is intended to be 100% backwards compatible. anonymous wrote : | In terms of "Should the ServiceController create the Kernel internally | or should it be created by the ServerLoader and "injected" | in the ServiceController?", can't this only be the latter? Currently the profileserivce version of the ServerLoader/ServerImpl (which is in head but not used by default: org.jboss.system.server.profileservice.ServerImpl) creates a single kernel for the entire server. | Ok, That decides that. Just need a new constructor new ServiceController(Kernel kernel) or a setKernel() method. anonymous wrote : | Back to the discussion of allowing interaction between legacy mbeans and new kernel beans how can this be done unless they are in the same kernel? | Yes, there should be one kernel. I do plan to support heirarchical kernels in the future when I get the scoping finished, e.g. being able to deploy a DataSource at the JMS subsystem level or deploy aspects into an AOPDomain at the deployment level but even these should be off one root. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962953#3962953 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962953

20 years

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-1841 - ServiceController/Microcontainer integration

by scott.stark＠jboss.org

The new VDF MainDeployer and porting of the SARDeployer to the VDF will be the collision point. I'll try to merge these changes into my working copy of head today. Do we want to synch up with all the current head changes and make another javaee cts branch or do this mc/vdf/profilesevice work in a branch? In terms of "Should the ServiceController create the Kernel internally or should it be created by the ServerLoader and "injected" in the ServiceController?", can't this only be the latter? Currently the profileserivce version of the ServerLoader/ServerImpl (which is in head but not used by default: org.jboss.system.server.profileservice.ServerImpl) creates a single kernel for the entire server. Back to the discussion of allowing interaction between legacy mbeans and new kernel beans how can this be done unless they are in the same kernel? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962947#3962947 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962947

20 years

1
0
0 / 0

[Design of Security on JBoss] - Re: Changes to Realm Interface sought

by anil.saldhana＠jboss.com

Hence the need for support in Realm interface (or atleast RealmBase with an extra method I suggested) to support authentication greater than the four stripped down authenticate methods that are legacy. When JSR-196 becomes mandatory for JEE6, there will be a push for this anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962941#3962941 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962941

20 years

1
0
0 / 0

[Design of Security on JBoss] - Re: Changes to Realm Interface sought

by j2ee_junkie

Bypassing the realm as you state has another possible side-effect. It will break current Tomcat authorization calls (which are made to the Realm). So that is not good. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962940#3962940 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962940

20 years

1
0
0 / 0

[Design of Security on JBoss] - Re: Changes to Realm Interface sought

by anil.saldhana＠jboss.com

AFAICT, introduction of a custom authenticator , will not make the call-out to a realm mandatory, because there is no requirement on the custom authenticator to call the realm interface. It can do its job inhouse. But this will lead to a lot of duplication in authenticator code. It certainly does not make sense for the realm interface to have scaled down information plucked from the request object. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962934#3962934 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962934

20 years

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-1841 - ServiceController/Microcontainer integration

by adrian＠jboss.org

Work still to do: 1) Mostly more testing. The unit tests for errors are incomplete except for the "instantiation" tests. The different methods of describing attributes needs to be tested. There are currently no tests for XMBeans (except JBoss5 itself :-) I would have liked to complete these tests before committing, but I also wanted to get this into the codebase before Scott breaks it with the deployer changes. :-) 2) MetaData model There is a ServiceMetaData model which needs enhancing to expose some of the newer features now possible with the Microcontainer in control, e.g. <mbean ... mode="On Demand"> 3) JMX/POJO cross injection This should already work underneath, but there is no real way to describe it at the moment. a) The -service.xml needs an <attribute name="Blah"><inject bean="POJO"/></attribute b) The Bean deployer needs to be udpated to use the Kernel created by the ServiceController rather than creating a new one for each deployment. 4) Other bits and pieces There's a number of minor bits and pieces to tidyup. e.g. Should the ServiceController create the Kernel internally or should it be created by the ServerLoader and "injected" in the ServiceController? e.g.2 The IncompleteDeploymentException thrown by the MainDeployer needs updating to use the DependencyInfo from the underlying microcontainer controller so it picks up both JMX and POJO contexts etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962930#3962930 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962930

20 years

1
0
0 / 0

[Design of Security on JBoss] - Re: Changes to Realm Interface sought

by scott.stark＠jboss.org

This is needed to support custom authenticators. The current hard-coded mapping of authentication credentials to the Realm interface does not allow for authentication mechanisms outside of those currently understood by the servlet spec. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962926#3962926 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962926

20 years

1
0
0 / 0

[Design of POJO Server] - JBAS-1841 - ServiceController/Microcontainer integration

by adrian＠jboss.org

I've committed the initial work for this into jboss-head. This basically reproduces what the ServiceController did before except with the Microcontainer model underneath. There are two main differences with how it worked before, neither should affect working implementations. These are mainly about the Microcontainer's controller being more consistent with states. 1) When an error occurs, the MBean is returned to the NOT_INSTALLED state. In the old service controller, nothing much was done to rollback the state, it was just marked at FAILED. What did occur happened at remove(). Where it would invoke destroy() and unregisterMBean() regardless of what state it reached prior to failure. If you MBean implemented ServiceMBeanSupport you wouldn't notice this, since its internal lifecycle would ignore any spurious destroy() request. 2) The other main difference is that errors during "Instantiation" (i.e. mbean registration) still allow the MBean to remain under the controller's control and thus appear in the summary of errors of the "IncompleteDeploymentException". In the old service controller, the instantiation was done during the parsing of the xml which meant the context was lost if it errored. In the new controller, only xml parsing errors or attempts to register duplicate MBeans will lead to the context being unknown for error summary. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3962925#3962925 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3962925

20 years

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 August 2006