[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1593) New processing for stateful bean @Destroy and @Remove causes problems.
by Chris Rudd (JIRA)
New processing for stateful bean @Destroy and @Remove causes problems.
----------------------------------------------------------------------
Key: JBSEAM-1593
URL: http://jira.jboss.com/jira/browse/JBSEAM-1593
Project: JBoss Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0.BETA1
Reporter: Chris Rudd
I have an EJB that has several methods marked as @Remove, as I want the bean remove whenever those methods are executed.
One of which is marked as @Destroy, which is the ONLY one that should be called because the object is being destroyed (ie from a call to Component.destroy. The problem is that under the new processing rules the "defaultRemoveMethod is set to the last parameterless @Remove method.
I would suggest that the defaultRemoveMethod only be set to a "found @Remove" method if the @Destroy method has not been defined / does not have the @Remove annotation.
my class :
class Foo {
@Destroy
@Remove
public void cleanup() { /* does state cleanup*/ }
@Remove
public String removeEntity() { /* does some work*/ }
}
For this class cleanup is executed because its the destroy method, then removeEntity is executed since it was the last @Remove method found.
--
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, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1602) exception handler not recognizing end-conversation
by Hung Tang (JIRA)
exception handler not recognizing end-conversation
--------------------------------------------------
Key: JBSEAM-1602
URL: http://jira.jboss.com/jira/browse/JBSEAM-1602
Project: JBoss Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0.BETA1
Environment: Seam-CVS
Reporter: Hung Tang
In my application, I'm using pages.xml exception handling mechanism to automatically end conversations when optimistic locking exceptions ever arise.
This is what I have
<exception class="javax.persistence.OptimisticLockException">
<end-conversation/>
<redirect view-id="/p/home.xhtml">
<message severity="ERROR">#{messages['concurrentmodification']}</message>
</redirect>
</exception>
However, when it does come up, the conversation is not ending as I want.
I could reproduce this error in the contact-list example. Just add begin propagation to the editContact and the exception handler will recognize it as a javax.persistence.PersistenceException, but it will not end the conversation as you have told it to.
--
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, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1584) @Logger and Spring beans
by Magnus Heino (JIRA)
@Logger and Spring beans
------------------------
Key: JBSEAM-1584
URL: http://jira.jboss.com/jira/browse/JBSEAM-1584
Project: JBoss Seam
Issue Type: Feature Request
Components: Spring
Affects Versions: 2.0.0.BETA1
Reporter: Magnus Heino
It would be nice if spring beans could be scanned for @Logger and injected with Log instances just like seam components.
Using the code below, you can add this to applicationContext.xml...
<bean class="org.jboss.seam.ioc.spring.LoggerPostProcessor" />
...to have all spring beans scanned for @Logger and have a Log instance injected, just like seam components. Then you can access the same context and log functionallity in your spring beans as in your seam components.
I guess the seam spring namespace could be extended with <seam:logger/> to make it even more simple to use.
package org.jboss.seam.ioc.spring;
import java.lang.reflect.Field;
import org.jboss.seam.annotations.Logger;
import org.jboss.seam.log.Logging;
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.config.BeanPostProcessor;
import org.springframework.util.ReflectionUtils;
import org.springframework.util.StringUtils;
import org.springframework.util.ReflectionUtils.FieldCallback;
public class LoggerPostProcessor implements BeanPostProcessor {
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
return bean;
}
public Object postProcessBeforeInitialization(final Object bean, final String beanName) throws BeansException {
ReflectionUtils.doWithFields(bean.getClass(), new FieldCallback() {
public void doWith(Field field) throws IllegalArgumentException, IllegalAccessException {
if (field.isAnnotationPresent(Logger.class)) {
String category = field.getAnnotation(Logger.class).value();
if(!StringUtils.hasText(category)) {
category = bean.getClass().getName();
}
ReflectionUtils.makeAccessible(field);
field.set(bean, Logging.getLog(category));
}
}
});
return bean;
}
}
--
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, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1484) Seam-gen should generate pages using templates relative to web application, not the pages themselves
by Dejan Krsmanovic (JIRA)
Seam-gen should generate pages using templates relative to web application, not the pages themselves
----------------------------------------------------------------------------------------------------
Key: JBSEAM-1484
URL: http://jira.jboss.com/jira/browse/JBSEAM-1484
Project: JBoss Seam
Issue Type: Patch
Components: Tools
Affects Versions: 1.3.0.ALPHA
Reporter: Dejan Krsmanovic
Priority: Minor
Attachments: seam-gen.txt
Seam-gen currently creates facelets xhtml pages having ui-composition element with template attribute specified relative to page itself. This is OK if all pages are stored in the root folder of web application. However, when you start refactoring and moving pages to separate folders you need to update template attribute in all ui-composition elements in moved pages.
So, I think seam-gen should generate pages with ui-composition element which references template relative to web-app, and not the page. In other words instead of:
<ui:composition ... template="layout/template.xhtml">
it should be:
<ui:composition ... template="/layout/template.xhtml">
With this change, you can move xhtml pages to any folder and template would still be referenced correctly.
--
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, 10 months