[Security & JAAS/JBoss] - Re: JBOSS SSO on JBOSS4.0.5 and Vista
by sohil.shahï¼ jboss.com
Nipun-
from the sounds of the scenario, looks like for some reason the token issued when logging into application 1 is not being trusted when logging into site 2,3,4.
The trust server is a component of the federation server.
Couple of things I can suggest is:
If all the four sites are running in the same domain, make sure there is only one instance of the Federation Server running on this domain (Federation Server has the trust component).
Also, in the jboss-sso.sar/conf/sso.cfg.xml, make sure all four sites are pointing to this Federation Server for the trust component.
Also can you provide details on what browser on which OS and what version you are using to test this.
Also, did you try running Application 1 in Vista on JBoss-4.0.3 and see?
Just some things to isolate the issue
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4022868#4022868
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4022868
19Â years, 1Â month
[JBoss Seam] - JSF and TransactionalSeamPhaseListener
by awheeler
This is more a question of design or understanding:
In order to avoid the lazy initialization exception I have followed the seam examples and used the TransactionalSeamPhaseListener and configured the components.xml correctly. The entity manager is now injected using the @In annotation. I can now retrieve my entities without problem however this raises an issue about JSF model updates which over-write the primary key of a ManyToOne entity.
Example:
| EJB3:
| @Entity
| public class Person extends {
| private Title title;
|
| @ManyToOne(cascade = {}, fetch = FetchType.EAGER)
| @JoinColumn(name = "title_id", unique = false, nullable = true, insertable = true, updatable = true)
| public Title getTitle() {
| return this.title;
| }
| .
| .
| }
|
| Backing Bean:
| @Stateful
| @Scope(ScopeType.CONVERSATION)
| @Name("editPerson")
| public class EditPerson {
| @In
| private EntityManager entityManager;
| @Out
| private Person person;
| .
| .
| }
|
| JSF:
| <h:selectOneMenu id="titleId" value="#{person.title.titleId}"/>
|
The problem occurs when the title is changed in the selectOneMenu from say "Mr" to "Mrs". JSF applies its model changes to person.title.titleId which changes the primary key of the managed entity. Any calls to persist the person entity fail as two title objects exist with the same primary key This seems to be a general problem for JSF pages wanting to write directly to managed entities.
To avoid this problem I have reverted to the standard SeamPhaseListener and use the @PersistenceContext. The entity is now "disconnected" and calls to merge() no longer complain about the change in primary key they just perform the update. i.e update person set titleId=2 . . .
This solution means that I have to initialise every lazy collection manually before passing it to JSF.
A possible solution is to intercept the model update before it is applied and set the title on person to the changed title:
| newTitleId = {Get model value for titleId}
| newTitle = em.find(Title.class, newTitleId)
| person.setTitle(newTitle)
| {Stop model update of person.title.titleId}
|
Another solution is have all selectOneMenus writing their value back to a property on the backing bean instead of the entity. This however really curbs flexibility with reuse.
How should I do this? Is there a better way? Does anyone have a better design solution?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4022862#4022862
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4022862
19Â years, 1Â month
[EJB 3.0] - Entity Callbacks for collection attributes
by jmale
Hi,
we use JBoss AS 4.0.4 in clustered mode with the EJB3 container configured.
For JAAS, we store users, roles etc in a MySQL database and configure this in the login-config.xml file as normal.
We also allow a client application to modify users, user groups and the roles to which they are assigned. To facilitate this, we use the EJB3 JPA layer to map the database tables to "entities", these being 'User', 'UserGroup' and 'Role'.
Each of these entities has their own independent lifecycle. There is a bidirectional many-to-many relationship between 'User' and 'UserGroup' with 'User' being the owning side (see the snippet below):
@ManyToMany(cascade = { CascadeType.PERSIST, CascadeType.MERGE }, fetch = FetchType.EAGER)
| @JoinTable(name = "UserToUserGroupMap",
| joinColumns = {@JoinColumn(name = "principalFK")},
| inverseJoinColumns = {@JoinColumn(name = "groupFK")})
| @Cache (usage=CacheConcurrencyStrategy.TRANSACTIONAL)
| public Set<UserGroup> getUserGroups()
| {
| return this.userGroups;
| }
There is a unidirectional many-to-many relationship between 'UserGroup' and 'Role'(see the snippet below):
@ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE}, fetch = FetchType.EAGER)
| @JoinTable(name = "UserGroupToRoleMap",
| joinColumns = {@JoinColumn(name = "groupFK")},
| inverseJoinColumns = {@JoinColumn(name = "roleFK")})
| @Cache (usage=CacheConcurrencyStrategy.TRANSACTIONAL)
| public Set<Role> getRoles()
| {
| return this.roles;
| }
When a client/transaction updates on of these entity instances, we want to capture that event so that the other clients can be notified of the update. To achieve this we wanted to use the JPA entity callback mechanism. For each of the above entities, we added a callback such as:
| @PostUpdate
| void notifyObserversOfEntityUpdate()
| {
| // notify observers (performed asychronously using JMS)
| }
It seems as though this callback is executed whenever a normal entity attribute is modified. It does not seem to be called if one of the many-to-many associations detailed above is modified however.
At this point, I turned on hibernate TRACE level logging and noticed that collection attribute changes seem to be treated differently to non-collection attrubte changes. If one of the many-to-many collection attributes is modified, I see the following logs (please ignore the insertion as that is for another unrelated entity but still part of the same transaction):
2007-02-22 10:39:55,274 TRACE [org.hibernate.event.def.AbstractFlushingEventListener] Scheduling collection removes/(re)creates/updates
2007-02-22 10:39:55,276 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] Flushed: 1 insertions, 0 updates, 0 deletions to 4 objects
2007-02-22 10:39:55,276 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] Flushed: 1 (re)creations, 0 updates, 1 removals to 4 collections
However, if a non-collection attribute is modified, I see logs such as the following (please ignore the insertion as that is for another unrelated entity but still part of the same transaction):
2007-02-22 13:23:23,051 TRACE [org.hibernate.event.def.AbstractFlushingEventListener] Scheduling collection removes/(re)creates/updates
2007-02-22 13:23:23,051 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] Flushed: 1 insertions, 1 updates, 0 deletions to 4 objects
2007-02-22 13:23:23,051 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] Flushed: 0 (re)creations, 0 updates, 0 removals to 4 collections
What I would like to know is whether this is by design or whether it is a bug. If it is by design, then is there a way using JPA that I can get callbacks when collections change. Or, do I have to use a Hibernate specific interceptor or something?
Thanks a lot...
Josh
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4022859#4022859
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4022859
19Â years, 1Â month