[Design of POJO Server] - ServiceController unregistering
by adrian＠jboss.org
I was seeing the following warning in jboss-head
| 14:25:15,021 WARN [AbstractKernelController] Error uninstalling from Instantiated: name=jboss.system:service=ServiceController state=Instantiated
| java.lang.IllegalArgumentException: Null MBeanServer
| at org.jboss.system.ServiceCreator.uninstall(ServiceCreator.java:303)
| at org.jboss.system.microcontainer.OnlyUnregisterAction.uninstallAction(OnlyUnregisterAction.java:45)
| at org.jboss.system.microcontainer.ServiceControllerContextAction.uninstall(ServiceControllerContextAction.java:90)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
| at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:311)
| at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1320)
| at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1009)
| at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:936)
| at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:463)
| at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:426)
| at org.jboss.dependency.plugins.AbstractController.shutdown(AbstractController.java:168)
| at org.jboss.bootstrap.microcontainer.ServerImpl.doShutdown(ServerImpl.java:162)
| at org.jboss.bootstrap.AbstractServerImpl.shutdownServer(AbstractServerImpl.java:497)
| at org.jboss.bootstrap.AbstractServerImpl$ShutdownHook.run(AbstractServerImpl.java:778)
|
This was due to the JMXKernel unregistering the ServiceController
from the MBeanServer and then only later does the new MC shutdown
spot that it was still registered with it.
It tries to uninstall but gets an error because the ServiceController
has lost its reference to the MBeanServer in the previous JMX uninstall.
I've fixed the problem such that the ServiceController removes itself
from both by doing an MC.uninstall() of itself during its shutdown.
But this isn't a very clean solution.
The (un)registrations are not symmetric.
The fundamental problem comes from the self bootstrap where
the ServiceController registers with itself and therefore it
doesn't follow the usual pattern.
Maybe there is a cleaner way to do this?
In fact, the only reason the self bootstrap exists was to be able to
place a dependency on the service controller.
If the ServiceController were just a POJO with the @JMX
annotation then we should have the required behaviour
in jboss-head using the cross injection of POJOs into MBeans?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079594#4079594
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079594
16 years, 8 months
[Design of JBoss Portal] - Re: Initiall identity model discussion
by Antoine_h
Hello,
here a few things that the Boleslaw post make me think of :
// ***********************************************
1) Identity Model
// ***********************************************
yes for all.
plus : the Model could be open/extendable with general java object (in the properties/attributes).
There is this in the user profile properties mechanisme, but it may be with direct access from the user (see here under).
The java objects would contains all the details of the users, that are company specific.
Informations that are implied in the authorization processing
Such as :
- Organisation, subsidiary, department the User belong to.
- Activity the user is working in (call center, accounting, ...)
All these information are not "portal requiered", but the portal user may carry the one that are involved in the authorization processing.
There is an example of this in the UserDetail concept/class in Acegi.
Then the authorization manager can be the same for all the application (portal and other company application). Easier for integration, maintenance... and security reliability.
// ***********************************************
1 bis) Identity Model processing (create, modify, suspend, suppress...)
// ***********************************************
I have just found another problem in the Identity Services.
Lets say the UserBP (business process <=> company User) has a typical Audit capability (creator id, creator date, modifier id, modifier date).
This audit capability is typical to know who has created the user, who has modified some role, and when.
The UserService, as a JMX service, has no idea of all this. With the API methods there is no way to add this kind of feature to any User/Role manipulation.
I think adding a "IdentityTreatmentContext" parameter in all the methods of the Identity Services would allow to implement specific treatment in the methods.
It will allow to extend the User/Role features, when creating, modifying, suspending a user.
The requester that call the method would provide the proper IdentityTreatmentContext and the specific implementation of the service would do the work with it.
Another example : today, the ldap is queried through the data source, with only one user defined for all the queries. If the query of the source (ldap, db, legacy) require some "who is asking this information about a user", the IdentityTreatmentContext param is a way to extends the Identity Services to this company specific feature.
(this is like the command model of the portal controler... Julien's way of doing ;-).
// ***********************************************
3) Authorization
// ***********************************************
The rule based authorization model seems very good.
I had no time to look at the Seam one.
First time I see something (open source) like that.
On my opinion, could be a separate project of JBoss.
The Authorization processing can be complex : the information requiered to do that work could be in a property dedicated to that.
The API of User could give direct access to it, and not through the heavy profile property mechanism.
// ***********************************************
4) Portal - communities
// ***********************************************
As for me, yes, these services/application are part of the whole bunch of application federated inside a portal. As well as any company application.
// ***********************************************
5 ) Business Process application of the companies
// ***********************************************
I mean any application that is part of the information system of a company.
In a insurance company I worked for recently, the portal is used to provide the tool to any employee, with the internal business application (no forum, no google gadget...).
The issue in this case is to provide the user identification and authorization to the portal, that is related to the business process authorisation.
Example : a user has the authorization to provide a proposal to a customer (very fine grained security model).
Another one has the authorization for only viewing a proposal, but not build one.
The portal must see, for both, the authorization to access to the Page/window/instance/portlet that provide the "proposal builder" (view mode for all these portalobject).
There is a kind of matrix of the portal authorization against the business authorization.
The rule base mechanism should be usefull for this.
In many cases, the organisation that uses the portal for federating some application will :
- provide it's source of users and authorization model and implementation
- plug this into the portal api and services
- rewrite all the user/role administration tools (as a user is never created "from scratch", but belong to a sub organisation, department, etc...). Or use it's own other tool for user admin.
// ***********************************************
A) naming
// ***********************************************
User and Role is short and nice.
but in an organisation, the portal is one application among the other.
the "User" and "Role" are the word used to talk about the one of the company : wider definition of User and Role than the one for the portal.
I would name these interface "UserPortal" and "RolePortal", and let free the User and Role class names.
Even with packaging, it is more clear for java developers.
When building a bridge between the User/Role for the portal and the User/Role from the business process, the code is much more precise and clear.
// ***********************************************
Globally :
// ***********************************************
- the portal Identity framework must support only what is requiered for the portal. It is a sub part of the organisation identity/security definition.
- provide a very extendable api with a "mechanism of bridge" between the
User/Authorisation feature for the portal, and the global one of the company.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079589#4079589
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079589
16 years, 8 months
[Design of JBoss Portal] - Re: hibernate session handling
by julien＠jboss.com
This is done programmatically in org.jboss.portal.jems.hibernate.SessionFactoryBinder
| // Force transaction manager lookup class and JTA env
| setPropertyIfAbsent("transaction.auto_close_session", "true");
| setPropertyIfAbsent("transaction.flush_before_completion", "true");
| setPropertyIfAbsent("hibernate.transaction.flush_before_completion", "true");
| setPropertyIfAbsent("hibernate.transaction.factory_class", "org.hibernate.transaction.JTATransactionFactory");
| setPropertyIfAbsent("hibernate.transaction.manager_lookup_class", "org.hibernate.transaction.JBossTransactionManagerLookup");
|
Transaction demarcation occurs in the server interceptor org.jboss.portal.core.aspects.server.TransactionInterceptor.java, the transaction demarcation is delegated to a JBoss AOP aspect which applies on the TransactionInterceptor, found in portal-aop.xml
| <metadata
| tag="transaction"
| class="org.jboss.portal.core.aspects.server.TransactionInterceptor">
| <method name="invoke">
| <trans-attribute>RequiresNew</trans-attribute>
| </method>
| </metadata>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4079546#4079546
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4079546
16 years, 8 months