[JBoss JIRA] Created: (JBPORTAL-1545) HibernateUserModuleImpl.removeUser potential unwanted NPE
by Antoine Herzog (JIRA)
HibernateUserModuleImpl.removeUser potential unwanted NPE
---------------------------------------------------------
Key: JBPORTAL-1545
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1545
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Identity
Affects Versions: 2.6 Final
Environment: 2.6.0GA
Reporter: Antoine Herzog
Priority: Minor
Fix For: 2.6.1 Final
In HibernateUserModuleImpl
In the removeUser method
code is :
String userName = user.getUserName();
if (user == null)
{
throw new NoSuchUserException("No such user " + id);
}
session.delete(user);
session.flush();
//fire events
fireUserDestroyedEvent(id, userName);
This first line will throw a NPE, and the null test is done after.
The code should be :
if (user == null)
{
throw new NoSuchUserException("No such user " + id);
}
String userName = user.getUserName();
session.delete(user);
session.flush();
//fire events
fireUserDestroyedEvent(id, userName);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years
[JBoss JIRA] Created: (JGRP-551) FD does not restart monitor task after unsuspect event
by Rodrigo Faria (JIRA)
FD does not restart monitor task after unsuspect event
------------------------------------------------------
Key: JGRP-551
URL: http://jira.jboss.com/jira/browse/JGRP-551
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4.1 SP3, 2.5
Environment: Found in JGroups 2.4.1SP3 and 2.5RC1. Used Windows XP but seems to be plataform independent.
Reporter: Rodrigo Faria
Assigned To: Bela Ban
I reproduced this with 3 members, but may be possible with only 2. FD and VERIFY_SUSPECT must be present in the configuration. The steps to reproduce are the following:
- jgroups with 3 members online
- disconnect a member (not the coord)
- wait until the member disconnected suspects the other two (FD will generate the suspect event for both), but before it changes its view (before VERIFY_SUSPECT confirms the suspection), and reconnect it.
When both suspection occured, FD will have stopped its monitor task (since it had no pingable members). When the unsuspect event is generated, the FD will not restart its monitor task. As a consequence of this, if the other members removed this member from their view, this member will not be shunned (assuming shun=true in FD), since FD is not sending heartbeat request . This member's FD also will not be able to identify any failure, since its monitor task is stopped (I think it will be restarted only if something triggers a VIEW_CHANGE).
I tried to change the unsuspect method in FD to update the pingable_members and ping_dest and restart the monitor task (something like the implementation for processing a VIEW_CHANGE event) and it seemed to correct this problem.
I also noticed ping_dest is not being sychronized in the monitor task. Instead of using a synchronized block (to prevent a bottleneck), I think it should be copied to a local variable so it is thread_safe (would prevent checking one member and suspecting another because the ping_dest changed). I did not reproduced this, I just noticed it looking at the source code.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years
[JBoss JIRA] Created: (JBMICROCONT-109) Support direct registration of beans without a StandardMBean wrapper
by Brian Stansberry (JIRA)
Support direct registration of beans without a StandardMBean wrapper
--------------------------------------------------------------------
Key: JBMICROCONT-109
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-109
Project: JBoss MicroContainer
Issue Type: Sub-task
Components: General
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossMC_2_0_0 Beta
If a bean is already a valid MBean, it should be possible to directly register it in JMX without wrapping it in a StandardMBean. Otherwise beans that implement things like MBeanRegistration, NotificationBroadcaster, NotificationEmitter will not expose that API to the mbean server.
To support this, @JMX will add an attribute:
boolean registerDirectly() default false;
JMXIntroduction will check the attribute; if true the target bean will be registered directly; otherwise a StandardMBean will be created and registered.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years
[JBoss JIRA] Created: (JBPORTAL-1562) Isolate Identity services in separate .sar
by Antoine Herzog (JIRA)
Isolate Identity services in separate .sar
------------------------------------------
Key: JBPORTAL-1562
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1562
Project: JBoss Portal
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Portal Identity
Affects Versions: 2.6 Final
Environment: JBP2.6.0
Reporter: Antoine Herzog
Priority: Minor
Fix For: 2.8 Final
All the classes of Identity are in a jar (portal-identity.jar).
The configuration is in several folders :
"deploy\jboss-portal.sar\conf\hibernate\user/"
and
"deploy\jboss-portal.sar\conf\identity"
May be it is possible to bundle all the identity features in a separate (sub) sar of the portal.
And also provide a deploy option to build :
- Hibernate implementation only
- LDAP implementation only
- Both
Usecase :
- More clean, for customization
- Ability to remove the original JBoss Portal portal-identity.sar and deploy a new customized one
More more easy for release upgrade than writting in the files of jboss-portal.sar.
- Ability to avoid having the LDAP config in prod that does not use LDAP.
- More easy to build automatic test, for various User and Role implementation (Hib, LDAP, ... EJB3 coming ?)
- More easy for providing other identity storage and management (community or vendors).
I guess that should work.
may be check a few things :
- deployement : make sure that all goes fine when the server start (this service is vital for a lot of major portal services)
- make sure all is fine with CMS needs etc... see Jira : http://jira.jboss.com/jira/browse/JBPORTAL-1499
- adaptation of the documentation
I have adapted the Hibernate implementation, to work with some "extended User and Role".
Works fine.
But not easy (not clean) to set the configuration in the original files (and will not also for upgrades like next 2.6.1).
By the way : Identity is widely used in systems. May be this implementation (services, controlers, etc...) could become a separate JBoss AS module (not only for portal) ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years