[Design of JBoss Identity] - User in API, User for business process in companies
by Antoine_h
Hello,
Thanks a lot for this huge step (I just see now) on this project !
My questions are about the User class and User Id.
Related to systems integration in companies.
they are related to this post for design issue and proposal here (Design of JBoss Portal forum) :
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=112843
the post : Sat Aug 4, 2007 15:46 PM
First question : User class : bridge between the "UserJBossIDProject" and "UserBPCompany".
usualy, for what I can see in many companies I work for, they have a "UserBPCompany".
It is provided by a source, a JMX service... etc... (internal framework or so). This source may run with JBoss also, or at least with Java.
Those are used in the BusinessProcess applications (most of the time, integrated inside some portal or so).
In the Identity project, there will be a "UserJBossIDProject" (overriden from the Identity interface, if I understood well).
The best way I have found to make the whole thing work (with User in Portal), is to build a kind of bridge beetwen the two classes : so to provide a "UserJBossIDProject" from the "UserBPCompany".
(see the other post for details).
I guess this will be easier with the new Identity Model ?
What about providing a template for this bridge, optional, but ready for integration if the company needs it ?
(forgive if I it is yet in the project, but I missed it).
Second question (related to one) : User Id :
the Id is Object.
What about using the java generics ?
<IDENTITY_ID>
and
public IDENTITY_ID getId();
this would be nice to more strongly type the Id : it can be Integer, Long,... or like in Hibernate, a more complex object.
This would allow to override the interface with IDENTITY_ID defined. And use this specialized interfaces with strong type.
Pros and cons I can see :
Pros :
- Id are very important. Having a strong typing is good for clean programming.
- Id of user are used every where in the business process code. many objects of the business process make some reference to some users (bank account of the user, this and that of the user....). This would avoid to cast it each time the Id is used in another class.
- As an example : Ids are manipulated in many ways. As an example, with some JSF gui, they are sent to the client as String, and converted back when processing the requests. There, making sure that in the java code, it is alwas the exact type that is used, with compilation complaigning... is crucial.
Cons :
- I guess the code would be more heavy. In the Identity project code, there would be the IDENTITY_ID every where, even if it relies only on Object.
- would force the use of Java 5
>From my point of view, related to helping integration in many companies, I think that the Pros is more important than the Cons.
For one project, I did the bridge (see the first question) mainly to have this Id strongly type in a "UserBPCompany" class... and reliable code for manipulating this Id.
***********
Globally, after rereading this post, I noticed something.
The project is defined with : "JBoss Identity IDM aims to provide a common identity model for various JBoss projects."
I guess my concern is more : "an identity model that is widely used in various JBoss projects, and that cooperates/interfaces easily and nicely with the other applications of JBoss users and developpers".
the others applications in companies are oftenly developped for JBoss and runs on JBoss server. But their User class is often more specific than the needs of the JBoss projects.
I hope my explaination is easy to understand, and it may help.
feel free to ask question if something is not clear in this post.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209217#4209217
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209217
17 years, 1 month
[Design the new POJO MicroContainer] - Re: Duplicate DeploymentContext registration
by alesj
This eliminates the duplicates:
| Index: deployers-structure-spi/src/main/java/org/jboss/deployers/structure/spi/helpers/AbstractDeploymentContext.java
| ===================================================================
| --- deployers-structure-spi/src/main/java/org/jboss/deployers/structure/spi/helpers/AbstractDeploymentContext.java (revision 83617)
| +++ deployers-structure-spi/src/main/java/org/jboss/deployers/structure/spi/helpers/AbstractDeploymentContext.java (working copy)
| @@ -993,12 +993,15 @@
| log.warn("Unable to register deployment mbean " + context.getName(), e);
| }
| }
| - List<DeploymentContext> children = context.getChildren();
| - for (DeploymentContext child : children)
| - registerMBeans(child, true);
| - List<DeploymentContext> components = context.getComponents();
| - for (DeploymentContext component : components)
| - registerMBeans(component, false);
| + if (this == context || registerContext == false)
| + {
| + List<DeploymentContext> children = context.getChildren();
| + for (DeploymentContext child : children)
| + registerMBeans(child, true);
| + List<DeploymentContext> components = context.getComponents();
| + for (DeploymentContext component : components)
| + registerMBeans(component, false);
| + }
| }
|
| /**
| @@ -1021,12 +1024,15 @@
| log.trace("Unable to unregister deployment mbean " + context.getName(), e);
| }
| }
| - List<DeploymentContext> children = context.getChildren();
| - for (DeploymentContext child : children)
| - unregisterMBeans(child, true);
| - List<DeploymentContext> components = context.getComponents();
| - for (DeploymentContext component : components)
| - unregisterMBeans(component, false);
| + if (this == context || unregisterContext == false)
| + {
| + List<DeploymentContext> children = context.getChildren();
| + for (DeploymentContext child : children)
| + unregisterMBeans(child, true);
| + List<DeploymentContext> components = context.getComponents();
| + for (DeploymentContext component : components)
| + unregisterMBeans(component, false);
| + }
| }
|
And another issue.
Isn't DeployersImpl::registerMBean called too early?
As at that point we don't have any components yet,
since the deployment hasn't gone yet through deployment stages.
It's just installed + manual mode --> Not_Installed state.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209212#4209212
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209212
17 years, 1 month