[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2264) @Observer with PostSetVariable produces Concurrent exceptions in a conversation scoped stateful bean
by Dan Hinojosa (JIRA)
@Observer with PostSetVariable produces Concurrent exceptions in a conversation scoped stateful bean
----------------------------------------------------------------------------------------------------
Key: JBSEAM-2264
URL: http://jira.jboss.com/jira/browse/JBSEAM-2264
Project: JBoss Seam
Issue Type: Bug
Affects Versions: 2.0.0.GA
Environment: java 6_u03, jboss-4.2.1GA, jboss-seam-2.0.0.GA
Reporter: Dan Hinojosa
A method with an @Observer that listens to a postSetVariable event:
@Name("myModule")
@Scope(ScopeType.CONVERSATION)
@Stateful
public class MyModule implements ModuleLocal, ModuleRemote {
@Observer("org.jboss.seam.postSetVariable.foo")
public void process() {
/* Do something */
}
}
produces a stack trace:
[SeamPhaseListener] uncaught exception
javax.el.ELException: javax.ejb.EJBTransactionRolledbackException: no concurrent calls on stateful bean 'jboss.j2ee:service=EJB3,name=MyModule' (EJB3 4.3.13)
According to 3.1.10. Concurrency model of the 2.0.0 documentation:
Finally, Seam enforces a single thread /per conversation per process/ model for the conversation context by serializing concurrent requests in the same long-running conversation context.
The two 'per' is kind of confusing, but it seems that since Seam is serializing concurrent requests, this issue should not occur.
Will create demo app shortly.
--
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
16 years, 9 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2243) org.jboss.seam.persistence.HibernateSessionProxy does not implement org.hibernate.event.EventSource
by Bojan Cekrlic (JIRA)
org.jboss.seam.persistence.HibernateSessionProxy does not implement org.hibernate.event.EventSource
---------------------------------------------------------------------------------------------------
Key: JBSEAM-2243
URL: http://jira.jboss.com/jira/browse/JBSEAM-2243
Project: JBoss Seam
Issue Type: Patch
Components: Core, EJB3
Affects Versions: 2.0.0.GA
Reporter: Bojan Cekrlic
When using the following search pattern:
FullTextEntityManager fullTextEntityManager = org.hibernate.search.jpa.Search.createFullTextEntityManager(em);
MultiFieldQueryParser parser = new MultiFieldQueryParser(new String[]{"username", "description"}, new SloAnalyzer());
org.apache.lucene.search.Query query = parser.parse( this.qs );
javax.persistence.Query hibQuery = fullTextEntityManager.createFullTextQuery( query, User.class );
The code dies with something in the lines of "FullTextHibernateSessionProxy cannot be cast to EventSource".
This happens because of constructor in org.hibernate.search.impl.FullTextSessionImpl:
public FullTextSessionImpl(org.hibernate.Session session) {
this.session = (Session) session;
this.eventSource = (EventSource) session;
this.sessionImplementor = (SessionImplementor) session;
}
The quick solution is to fix org.jboss.seam.persistence.HibernateSessionProxy (which is extended by FullTextHibernateSessionProxy) to implement org.hibernate.event.EventSource and add the following code:
public void delete(String arg0, Object arg1, boolean arg2, Set arg3) {
((EventSource) delegate).delete(arg0, arg1, arg2, arg3);
}
public void forceFlush(EntityEntry arg0) throws HibernateException {
((EventSource) delegate).forceFlush(arg0);
}
public ActionQueue getActionQueue() {
return ((EventSource) delegate).getActionQueue();
}
public Object instantiate(EntityPersister arg0, Serializable arg1)
throws HibernateException {
return ((EventSource) delegate).instantiate(arg0, arg1);
}
public void merge(String arg0, Object arg1, Map arg2)
throws HibernateException {
((EventSource) delegate).merge(arg0, arg1, arg2);
}
public void persist(String arg0, Object arg1, Map arg2)
throws HibernateException {
((EventSource) delegate).persist(arg0, arg1, arg2);
}
public void persistOnFlush(String arg0, Object arg1, Map arg2) {
((EventSource) delegate).persistOnFlush(arg0, arg1, arg2);
}
public void refresh(Object arg0, Map arg1) throws HibernateException {
((EventSource) delegate).refresh(arg0, arg1);
}
public void saveOrUpdateCopy(String arg0, Object arg1, Map arg2)
throws HibernateException {
((EventSource) delegate).saveOrUpdateCopy(arg0, arg1, arg2);
}
I have not gone into details if any of these methods need to do EL interpolation or not, but my first hunch tells me that either no or it's not important for this usage scenario.
--
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
16 years, 9 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2244) SpringTransaction doesn't pass the exception stack to the exception handler
by dapeng wang (JIRA)
SpringTransaction doesn't pass the exception stack to the exception handler
---------------------------------------------------------------------------
Key: JBSEAM-2244
URL: http://jira.jboss.com/jira/browse/JBSEAM-2244
Project: JBoss Seam
Issue Type: Feature Request
Components: Spring
Affects Versions: 2.0.0.GA
Reporter: dapeng wang
Fix For: 2.0.1.GA
currently if a tx will be rollbacked, the SpringTransaction class kind of swallow the root cause in the following code
Code:
catch (TransactionSystemException e)
{
log.error("Exception cause:", e);
throw new SystemException(e.getMessage());
}
catch (UnexpectedRollbackException e)
{
log.error("Exception cause:", e);
throw new RollbackException(e.getMessage());
}
The problem is that the SystemException and RollbackException defined in JTA seem not to be able to take the case exception. But it is essential to pass the whole cause exception in SystemException and RollbackException instead of only a text message.
My use case is the following:
JSF delete action method tries to delete a row in the db. When the tx commits, it discovers the row can not be deleted because of foreign key constraint. I would like to have the ConstraintViolationException wrapped in the RollbackException, so that I have a chance to handle this exception later with the exception handler.
In the current implmenetation, the RollbacklException with only text message and no cause stack will later be wrapped as an IllegalStateException, which is not helpful for exception handling at all.
Please make the cause exception somehow accessible (ThreadLocal, or Seam Event Context), so that the error handling mechanism has a chance to do an exception handling.
--
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
16 years, 9 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2132) consult class attribute on component XML declaration with namespace
by Dan Allen (JIRA)
consult class attribute on component XML declaration with namespace
-------------------------------------------------------------------
Key: JBSEAM-2132
URL: http://jira.jboss.com/jira/browse/JBSEAM-2132
Project: JBoss Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0.CR2
Reporter: Dan Allen
Assigned To: Dan Allen
Priority: Critical
Fix For: 2.0.1.GA
When a component template class is being configured (such as EntityHome, EntityQuery, etc), the class attribute should be considered prior to deriving the class name from the namespace info + XML element name. Doing so prevents the case where two components are being configured for the same name when the developer intends only to use it for configuration.
Case in point:
Let's say I create a class that extends EntityHome to provide some extra behavior.
@Name("myEntityHome")
public class MyEntityHome extends EntityHome {
}
Now I want to configure the properties of this class in components.xml
<framework:entity-home name="myEntityHome" class="org.example.model.MyEntityHome">
<framework:created-message>You created it! Yeah!</framework:created-message>
<framework:updated-message>You updated it! Yeah!</framework:updated-message>
<framework:deleted-message>You deleted it! Yeah!</framework:deleted-message>
</framework:entity-home>
If the class attribute is not consulted, it will look for a @Name annotation on org.jboss.seam.framework.EntityHome rather than org.example.model.MyEntityHome. When it doesn't find one on the built-in class, it tries to create a new component definition.
Why would I want to use XML namespace tags in this case? Simple. Tag completion and property recognition support.
Note that this works if the class resolved from XML namespace + element name is the same as the component class. In the case when the component class extends the built-in class, you get this problem.
--
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
16 years, 9 months