Prashanth Talapala

Disabling the cache of login credentials affects the credentials of the subject / principals.. However I am changing the method permission of an ejb session bean. The credentials are used to act on the ejb method... I am changing the ejb side permissions not the subject side credentials,... hence in this case i dont think flushing the login credentail cache makes a difference...

-P

Jboss : 4.0.4 GA
Ejb: 3.0


Hi all,
I am using JbossAS for my JEE application which involves ejb3. I have given role based permission to an ejb session bean method using annotations. This works fine along expected lines for allowing / denying users belonging to certain roles to access the method. However, when I try to change the role based ejb3 method permission on the fly, the policy configuration shows the role and permisiion have changed in the active policy map after commit() is called, but the container (JbossAS) shows the same behavior as before based on the old permissions given in the annotations during system startup. How can I change the ejb3 method permission on the fly and make the container aware of it? Please help me regarding this problem.

Thank you,
-P.

Hi all,
I have been using Hibernate-3.0.5 for my project and now I want to migrate to Hibernate-3.1 (version 3.1.3 to be exact). I noticed that a few classes which were public in Hibernate 3.0.5 are missing in Hibernate 3.1. The following classes are missing in the jar and in the Hibernate API documentation.

1. org.hibernate.persister.entity.BasicEntityPersister
2. org.hibernate.engine.CollectionSnapshot

The Hibernate migration guide does not make any mention of these files or their respective changes in the API.
Am I missing something here or is there a reason why these classes are missing in Hibernate 3.1 ?

Thank you,
Prashanth.

Ok three things seem odd here:

1. You dont need a transaction when you are reading from a db (i.e; using select queries). Transaction is required only when an update is done. So remove the transaction related code from your code.

2. Try setting a scroll mode in the query. i,e; instaed of query.scroll() try using something like query.scroll(ScrollMode.SCROLL_INSENSITIVE)

3. I guess scrollable resultset support in hibernate is dependent on the jdbc driver support. So i donno check your jdbc driver if it supports scrollable resultset.

I feel it may be a session related problem so try removing transaction related code and see how it goes. Let me know if it works ... or it doesnt

-Prashanth.

It looks like the hiberante Session is closed and then you want to insert / update the object. This will cause an error when it comes to lazy initialised elements of the object like Set, Map etc. Try to refresh the object from the db and then save it.

-Prashanth.

Can you post the code as to how you are reading the code? If you created a statement object from the connection u may need to specify what kind of a resultset it needs to return (i.e; scrollable etc.)

-Prashanth.

The unsaved-value="null" is used to identify a new first time to be persisted object from an object which is already persisted and is being updated. So when hibernate tries to persist an object it sees what the id value is. If the id value is null (in the case of a newly created object) then it assigns an id using the generator and persists the object. So which brings me to my earlier problem, I am getting a random error sometimes saying cant insert null as id into db. Why is that? is it because hibernate is unable to set an id or it is running out of ids??

-Prashanth.

<generator class="hilo">
<param name="max_lo">100</param>
</generator>

Hi all,
I seem to have a problem with setting the id of a bean when the bean is being saved for the first time. The id type="long" and the unsaved-value="null". Sometimes, when an object is being created and tried to be persisted I am getting an error that the id value is null and the object cannot be persisted. This error I am getting in a random fashion, which makes it harder to figure out the problem. Has anyone faced a similar problem? Should I use type="java.lang.Long" instaed of type="long" ? How does it matter what the type is? Please help me.