[JBoss Seam] - seam tries tio create a seam component from a class which is
by titou09
using seam 2.0 RC1
In a seam component, we are using Hibernate to "get" an instance of a persistent instance which is not a seam componnent and we receive an "IllegalArgumentException" .
It seems that, after Hibernate perfoemed the sql select, seam tries to "build" a seam component from a class which is *not* a seam component
Is this a bug? is this a configuration problem?
The "Utilisateur" class si a plain POJO... (We do't use EJB3..)
Also, we use <core:init transaction-management-enabled="false" /> in componente.xml
| @Name("utilisateurManager")
| @Scope(ScopeType.APPLICATION)
| @Startup
| public class UtilisateurManagerImpl extends ManagerHibernate implements UtilisateurManager {
| @In
| private Session sessionHibernate;
|
| @Transactional(TransactionPropagationType.REQUIRED)
| public Utilisateur obtenirUtilisateurParCodeUsager(String codeUsager) {
| return (Utilisateur) sessionHibernate.get(Utilisateur.class, codeUsager.toUpperCase());
| }
|
| [02/10/07 17:23:02:759 EDT] 00000028 viewhandler E Error Rendering View[/pages/accueil.xhtml]
| java.lang.IllegalArgumentException: Not an entity class: com.saq.pp.metier.modele.Utilisateur
| at org.jboss.seam.Entity.forClass(Entity.java:208)
| at org.jboss.seam.security.Identity.checkEntityPermission(Identity.java:665)
| at org.jboss.seam.security.HibernateSecurityInterceptor.onLoad(HibernateSecurityInterceptor.java:35)
| at org.hibernate.event.def.DefaultPreLoadEventListener.onPreLoad(DefaultPreLoadEventListener.java:18)
| at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:125)
| at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:854)
| at org.hibernate.loader.Loader.doQuery(Loader.java:729)
| at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
| at org.hibernate.loader.Loader.loadEntity(Loader.java:1860)
| at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
| at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
| at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3044)
| at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:395)
| at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:375)
| at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:139)
| at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:195)
| at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:103)
| at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878)
| at org.hibernate.impl.SessionImpl.get(SessionImpl.java:815)
| at org.hibernate.impl.SessionImpl.get(SessionImpl.java:808)
| at org.jboss.seam.persistence.HibernateSessionProxy.get(HibernateSessionProxy.java:181)
| at com.saq.pp.metier.manager.UtilisateurManagerImpl.obtenirUtilisateurParCodeUsager(UtilisateurManagerImpl.java:41)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
|
(Line UtilisateurManagerImpl.java:41 correspond to the sessionHibernate.get(..) statement)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090835#4090835
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090835
18Â years, 6Â months
[EJB 3.0] - Re: Working example por OneToMany cascade remove?
by rjstanford
So is it a fair statement to say that delete cascading does not and will not work on OneToMany relationships? How inconvenient.
We're using a stateful session bean (Seam) which allows us to keep changing the object model until the user is ready to either a) save or b) cancel. On a cancel its easy - we just walk away from everything. On a save, our goal was to simply end the conversation in the default manner, which has Hibernate flush all of the changes.
It sounds like we're going to have to keep track of the before/after state, descend through all of the OneToManys, to comparisons, and manually handle everything. It seems odd that CascadeType.REMOVE doesn't do this, since it certainly could follow the same logic - that's why I'm still hoping that we're missing some setting somewhere...?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090826#4090826
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090826
18Â years, 6Â months