November 2007 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1627) implement the barCode UCC/EAN 128

by Norman Richards (JIRA)

implement the barCode UCC/EAN 128 --------------------------------- Key: JBSEAM-1627 URL: http://jira.jboss.com/jira/browse/JBSEAM-1627 Project: JBoss Seam Issue Type: Feature Request Reporter: Norman Richards Fix For: 2.0.0.CR1 Need to add codeType for this. -- 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

2
3
0 / 0

[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, 9 months

4
7
0 / 0

[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, 9 months

3
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1615) @Begin with conversation id can't use conversation-scoped components

by Norman Richards (JIRA)

@Begin with conversation id can't use conversation-scoped components -------------------------------------------------------------------- Key: JBSEAM-1615 URL: http://jira.jboss.com/jira/browse/JBSEAM-1615 Project: JBoss Seam Issue Type: Bug Reporter: Norman Richards Assigned To: Norman Richards Reported from support issue. Using @Begin(id="...") doesn't actually work. The conversation gets created, but components in the conversation can't be seen, so new instances are created for every request -- 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

2
2
0 / 0

[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, 9 months

4
7
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1575) Add support for Spring managed transactions in jboss-seam-ioc

by Michael Youngstrom (JIRA)

Add support for Spring managed transactions in jboss-seam-ioc ------------------------------------------------------------- Key: JBSEAM-1575 URL: http://jira.jboss.com/jira/browse/JBSEAM-1575 Project: JBoss Seam Issue Type: Feature Request Components: Spring Affects Versions: 2.0.0.BETA1 Reporter: Michael Youngstrom Assigned To: Michael Youngstrom Fix For: 2.0.0.CR1 Since the non JTA transaction management floodgates appear to now be open perhaps I can add spring transaction management integration? -- 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

3
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1574) view-id actions are not called when rendering from a previous view-id

by Michael Youngstrom (JIRA)

view-id actions are not called when rendering from a previous view-id --------------------------------------------------------------------- Key: JBSEAM-1574 URL: http://jira.jboss.com/jira/browse/JBSEAM-1574 Project: JBoss Seam Issue Type: Bug Affects Versions: 2.0.0.BETA1 Reporter: Michael Youngstrom Fix For: 2.0.0.CR1 <page view-id="/list.xhtml"> <navigation> <rule if-outcome="detail"> <render view-id="/detail.xhtml"/> </rule> </navigation> </page> <page view-id="/detail.xhtml" action="#{bean.loadDetail}"/> Does not appear to call #{bean.loadDetail} when the list navigation rule is executed. Mike -- 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

6
32
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1564) NullPointerException in ServerConversationContext.flush

by Louis Coetzee (JIRA)

NullPointerException in ServerConversationContext.flush ------------------------------------------------------- Key: JBSEAM-1564 URL: http://jira.jboss.com/jira/browse/JBSEAM-1564 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 2.0.0.BETA1 Environment: Seam CVS build Wed Jun 27 2007, jboss 4.2.0GA, Linux Reporter: Louis Coetzee Fix For: 2.0.0.CR1 A NullPointerException occurs during in the org.jboss.seam.jsf.SeamPhaseListener -- 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

4
11
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1549) udpate XML version numbers

by Norman Richards (JIRA)

udpate XML version numbers -------------------------- Key: JBSEAM-1549 URL: http://jira.jboss.com/jira/browse/JBSEAM-1549 Project: JBoss Seam Issue Type: Task Reporter: Norman Richards Fix For: 1.3.0.BETA1 The XML needs to reflect seam 2.0 versioning -- 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

2
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1520) image files should not be filtered (property replacement)

by Dan Allen (JIRA)

image files should not be filtered (property replacement) --------------------------------------------------------- Key: JBSEAM-1520 URL: http://jira.jboss.com/jira/browse/JBSEAM-1520 Project: JBoss Seam Issue Type: Patch Components: Tools Affects Versions: 1.3.0.ALPHA Environment: seam CVS HEAD Reporter: Dan Allen Priority: Minor Images files in the seam-gen/view/img folder should not be filtered when they are moved over into the new project. Doing so causes them to become corrupt and the result is that they do not display in most browsers. A separate copy task should be used when moving these files during the new-project command. -- 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

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues November 2007