March 2012 - weld-issues - Jboss List Archives

[JBoss JIRA] (WELD-1) Add tests for multiple wars in an ear

by Ales Justin (JIRA)

[ https://issues.jboss.org/browse/WELD-1?page=com.atlassian.jira.plugin.sys... ] Ales Justin updated WELD-1: --------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.6.Final) > Add tests for multiple wars in an ear > ------------------------------------- > > Key: WELD-1 > URL: https://issues.jboss.org/browse/WELD-1 > Project: Weld > Issue Type: Feature Request > Components: Bootstrap and Metamodel API, Scopes & Contexts > Reporter: Pete Muir > Fix For: 1.2.0.Beta1 > > > This is a typical area of weakness in Seam etc. due to misuse of singletons etc. > Write some tests to check that multiple wars in an ear work as expected. For example that beans are not resolvable between the two unless there is classloader visibility, and that the servlet context from one is not mixed to another, and that bean instances do not leak. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WELD-53) Refactor reflection layer to be less of a memory hog

by Ales Justin (JIRA)

[ https://issues.jboss.org/browse/WELD-53?page=com.atlassian.jira.plugin.sy... ] Ales Justin updated WELD-53: ---------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.6.Final) > Refactor reflection layer to be less of a memory hog > ---------------------------------------------------- > > Key: WELD-53 > URL: https://issues.jboss.org/browse/WELD-53 > Project: Weld > Issue Type: Feature Request > Components: Resolution (Typesafe and by Name) > Reporter: Pete Muir > Priority: Blocker > Fix For: 1.2.0.Beta1 > > > Currently the reflection layer stores too much information, meaning we waste valuable heap space. This comes about because we build "extended metadata" for every deployed class; however we don't need this extended metadata for every class, and we also only need it at boot time. Therefore the proposed redesign looks like: > 1) Create lightweight AnnotatedType implementations (work done, see https://github.com/pmuir/weld-core/tree/WELD-13_initial_slim) > 2) Use these to fire the ProcessAnnotatedType events as needed (using the "backed" annotated impls) > 2a) If the annotated type is unchanged, keep the backed annotated impl. This is the annotated impl that will be kept around at runtime, and is designed to be as slimline as possible for mem usage, delegating everything possible to existing objects > 2b) If the annotated type is changed, wrap it in an "unbacked" annotated type. This may seem unecessary, however it does mean we are providing a consistent view for debugging, error reporting etc. > 3) If a bean is required for the AnnotatedType, load extended metadata for it. > 3a) This should be pluggable by the container, allowing something like jandex to be used if desired > 3b) I would propose we use a Map like structure on load, so that the api looks like: > ExtendedAnnotatedType ExtendedMetadataLoader.load(AnnotatedType type); > 3c) This extended metadata should include all the rich information available today on WeldClass and co, including stuff like being able to load methods by parameter annotations, meta-annotation support etc. > 3d) Beans are created, using the extended metadata > 3e) this extended metadata should have no references to it after bootstrap, allowing it to be removed at next gc run > Notes: > * Creating a parallel hierarchy of classes is not possible whilst preserving immutability, so extended metadata objects are not linked to each other, you traverse the graph using annotated type impls -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WELD-51) Extract Reflection layer into SPI to allow container to provide an enhanced (faster) impl

by Ales Justin (JIRA)

[ https://issues.jboss.org/browse/WELD-51?page=com.atlassian.jira.plugin.sy... ] Ales Justin updated WELD-51: ---------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.6.Final) > Extract Reflection layer into SPI to allow container to provide an enhanced (faster) impl > ----------------------------------------------------------------------------------------- > > Key: WELD-51 > URL: https://issues.jboss.org/browse/WELD-51 > Project: Weld > Issue Type: Feature Request > Components: Reflection layer > Reporter: Pete Muir > Priority: Critical > Fix For: 1.2.0.Beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (WELD-911) Shared dependent instance injection with circular reference through decorator

by Christian Bauer (JIRA)

Shared dependent instance injection with circular reference through decorator ----------------------------------------------------------------------------- Key: WELD-911 URL: https://issues.jboss.org/browse/WELD-911 Project: Weld Issue Type: Bug Components: Scopes & Contexts Affects Versions: 1.1.1.Final Reporter: Christian Bauer CDI spec section 6.4 says about @Dependent that "No injected instance of the bean is ever shared between multiple injection points." The following test shows that the same instance of @Dependent Foo is shared between multiple injection points, one in TestDecoratorInjection, the other in BarDecorator. {code} import org.jboss.weld.environment.se.Weld; import org.jboss.weld.environment.se.WeldContainer; import javax.annotation.PostConstruct; import javax.decorator.Decorator; import javax.decorator.Delegate; import javax.enterprise.inject.Any; import javax.inject.Inject; import javax.inject.Singleton; @Singleton public class TestDecoratorInjection { public static final Weld weld = new Weld(); public static final WeldContainer weldContainer = weld.initialize(); public static void main(final String[] args) throws Exception { weldContainer.instance().select(TestDecoratorInjection.class).get().test(); } @Inject Foo foo; // Dependent instance of TestDecoratorInjection void test() { foo.test(); } public static class Foo { @PostConstruct void init() { System.out.println("INIT FOO"); } @Inject Bar bar; // Dependent instance of Foo void print() { System.out.println("FOO"); } void test() { bar.print(); } } public static interface Bar { void print(); } public static class BarImpl implements Bar { @Override public void print() { System.out.println("Bar"); } } @Decorator public static abstract class BarDecorator implements Bar { @Inject @Delegate @Any Bar delegate; @Inject Foo foo; // Dependent instance of what?! @Override public void print() { foo.print(); } } } {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (WELD-760) Duplicate interceptor: More than one jar

by Robson Saraiva Ximenes (JIRA)

Duplicate interceptor: More than one jar ---------------------------------------- Key: WELD-760 URL: https://jira.jboss.org/browse/WELD-760 Project: Weld Issue Type: Bug Components: Weld SPI Affects Versions: 1.0.1.Final Environment: Just Weld 1.0.1.Final Reporter: Robson Saraiva Ximenes Assignee: Marius Bogoevici I'm getting the following error when I try to use my Interceptor: Duplicate interceptor class definition... The entire description for this issue was related here: http://seamframework.org/Community/AnotherInterceptorProblem -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

6
10
0 / 0

[JBoss JIRA] Created: (WELD-537) More details to WELD-000072 Managed bean declaring a passivating scope must be passivation capable.

by Nicklas Karlsson (JIRA)

More details to WELD-000072 Managed bean declaring a passivating scope must be passivation capable. --------------------------------------------------------------------------------------------------- Key: WELD-537 URL: https://jira.jboss.org/browse/WELD-537 Project: Weld Issue Type: Feature Request Components: Class Beans (Managed and Session) Affects Versions: 1.0.1.Final Reporter: Nicklas Karlsson The error message should be more detailed, currently ManagedBean.initializeAfterBeanDiscovery can have multiple conditions that set the passivationCapableBean to false (non-serializable interceptors etc) but it's hard to tell exactly what is wrong. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

5
8
0 / 0

[JBoss JIRA] (WELD-1019) Interceptor not applied on method of bean within custom scope.

by Rudy De Busscher (Created) (JIRA)

Interceptor not applied on method of bean within custom scope. -------------------------------------------------------------- Key: WELD-1019 URL: https://issues.jboss.org/browse/WELD-1019 Project: Weld Issue Type: Bug Components: Interceptors and Decorators, Scopes & Contexts Affects Versions: 1.1.3.SP1 Reporter: Rudy De Busscher Priority: Minor When the interceptor binding annotation is placed on a method (and class itself also) of a bean which is placed in a custom defined scope, the interceptor isn't executed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

4
4
0 / 0

[JBoss JIRA] (WELD-1007) Weld SE startup fails on openjdk7.

by Konstantin Gribov (Created) (JIRA)

Weld SE startup fails on openjdk7. ---------------------------------- Key: WELD-1007 URL: https://issues.jboss.org/browse/WELD-1007 Project: Weld Issue Type: Bug Components: Java SE Support Affects Versions: 1.1.2.Final, 1.1.1.Final Environment: Arch Linux, Linux kernel 3.0.7 java version "1.7.0_02-ea" Java(TM) SE Runtime Environment (build 1.7.0_02-ea-b11) Java HotSpot(TM) Server VM (build 22.0-b08, mixed mode) Reporter: Konstantin Gribov I use {{org.jboss.weld.environment.se.StartMain}} to bootstrap weld se environment. Project is compiled and packaged by maven. When starting assembly it fails with such stacktrace: {quote} Exception in thread "main" com.google.common.collect.ComputationException: java.lang.ArrayIndexOutOfBoundsException: 3 at com.google.common.collect.ComputingConcurrentHashMap.compute(ComputingConcurrentHashMap.java:218) at com.google.common.collect.ComputingConcurrentHashMap.apply(ComputingConcurrentHashMap.java:100) at com.google.common.collect.MapMaker$ComputingMapAdapter.get(MapMaker.java:515) at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:183) at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:128) at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:98) at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:54) at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:42) at com.google.common.collect.ComputingConcurrentHashMap.compute(ComputingConcurrentHashMap.java:206) at com.google.common.collect.ComputingConcurrentHashMap.apply(ComputingConcurrentHashMap.java:100) at com.google.common.collect.MapMaker$ComputingMapAdapter.get(MapMaker.java:515) at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:183) at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:128) at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:98) at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:54) at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:42) at com.google.common.collect.ComputingConcurrentHashMap.compute(ComputingConcurrentHashMap.java:206) at com.google.common.collect.ComputingConcurrentHashMap.apply(ComputingConcurrentHashMap.java:100) at com.google.common.collect.MapMaker$ComputingMapAdapter.get(MapMaker.java:515) at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:183) at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:95) at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:134) at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:191) at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:368) at org.jboss.weld.environment.se.Weld.initialize(Weld.java:92) at org.jboss.weld.environment.se.StartMain.go(StartMain.java:46) at org.jboss.weld.environment.se.StartMain.main(StartMain.java:59) Caused by: java.lang.ArrayIndexOutOfBoundsException: 3 at org.jboss.weld.introspector.jlr.WeldConstructorImpl.<init>(WeldConstructorImpl.java:113) at org.jboss.weld.introspector.jlr.WeldConstructorImpl.of(WeldConstructorImpl.java:70) at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:210) at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:98) at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:54) at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:42) at com.google.common.collect.ComputingConcurrentHashMap.compute(ComputingConcurrentHashMap.java:206) {quote} When I try to run this project in IntelliJ IDEA it works fine with such exec command: {quote} /home/gross/soft/jdk1.7.0_02/bin/java -Didea.launcher.port=7537 -Didea.launcher.bin.path=/opt/idea/bin -Dfile.encoding=UTF-8 -classpath /home/gross/soft/jdk1.7.0_02/jre/lib/deploy.jar:/home/gross/soft/jdk1.7.0_02/jre/lib/jce.jar:/home/gross/soft/jdk1.7.0_02/jre/lib/jsse.jar:/home/gross/soft/jdk1.7.0_02/jre/lib/rt.jar:/home/gross/soft/jdk1.7.0_02/jre/lib/management-agent.jar:/home/gross/soft/jdk1.7.0_02/jre/lib/javaws.jar:/home/gross/soft/jdk1.7.0_02/jre/lib/plugin.jar:/home/gross/soft/jdk1.7.0_02/jre/lib/resources.jar:/home/gross/soft/jdk1.7.0_02/jre/lib/charsets.jar:/home/gross/soft/jdk1.7.0_02/jre/lib/alt-rt.jar:/home/gross/soft/jdk1.7.0_02/jre/lib/ext/localedata.jar:/home/gross/soft/jdk1.7.0_02/jre/lib/ext/sunec.jar:/home/gross/soft/jdk1.7.0_02/jre/lib/ext/zipfs.jar:/home/gross/soft/jdk1.7.0_02/jre/lib/ext/dnsns.jar:/home/gross/soft/jdk1.7.0_02/jre/lib/ext/sunjce_provider.jar:/home/gross/soft/jdk1.7.0_02/jre/lib/ext/sunpkcs11.jar:/home/gross/crawler/app/target/classes:/home/gross/crawler/common/target/classes:/home/gross/.m2/repository/org/slf4j/slf4j-api/1.5.10/slf4j-api-1.5.10.jar:/home/gross/.m2/repository/org/jboss/resteasy/resteasy-jaxrs/2.2.2.GA/resteasy-jaxrs-2.2.2.GA.jar:/home/gross/.m2/repository/org/jboss/resteasy/jaxrs-api/2.2.2.GA/jaxrs-api-2.2.2.GA.jar:/home/gross/.m2/repository/org/scannotation/scannotation/1.0.3/scannotation-1.0.3.jar:/home/gross/.m2/repository/javassist/javassist/3.12.1.GA/javassist-3.12.1.GA.jar:/home/gross/.m2/repository/javax/annotation/jsr250-api/1.0/jsr250-api-1.0.jar:/home/gross/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar:/home/gross/.m2/repository/commons-httpclient/commons-httpclient/3.1/commons-httpclient-3.1.jar:/home/gross/.m2/repository/commons-codec/commons-codec/1.5/commons-codec-1.5.jar:/home/gross/.m2/repository/org/apache/httpcomponents/httpclient/4.0.3/httpclient-4.0.3.jar:/home/gross/.m2/repository/org/apache/httpcomponents/httpcore/4.0.1/httpcore-4.0.1.jar:/home/gross/.m2/repository/net/jcip/jcip-annotations/1.0/jcip-annotations-1.0.jar:/home/gross/.m2/repository/org/slf4j/slf4j-log4j12/1.5.10/slf4j-log4j12-1.5.10.jar:/home/gross/.m2/repository/log4j/log4j/1.2.16/log4j-1.2.16.jar:/home/gross/.m2/repository/org/slf4j/jcl-over-slf4j/1.5.10/jcl-over-slf4j-1.5.10.jar:/home/gross/.m2/repository/org/apache/commons/commons-io/1.3.2/commons-io-1.3.2.jar:/home/gross/.m2/repository/org/apache/commons/commons-compress/1.1/commons-compress-1.1.jar:/home/gross/.m2/repository/org/apache/james/apache-mime4j-dom/0.8-SNAPSHOT/apache-mime4j-dom-0.8-SNAPSHOT.jar:/home/gross/.m2/repository/org/apache/james/apache-mime4j-core/0.8-SNAPSHOT/apache-mime4j-core-0.8-SNAPSHOT.jar:/home/gross/.m2/repository/org/jboss/weld/se/weld-se-core/1.1.2.Final/weld-se-core-1.1.2.Final.jar:/home/gross/.m2/repository/org/jboss/weld/weld-spi/1.1.Beta2/weld-spi-1.1.Beta2.jar:/home/gross/.m2/repository/org/jboss/weld/weld-api/1.1.Beta2/weld-api-1.1.Beta2.jar:/home/gross/.m2/repository/org/jboss/weld/weld-core/1.1.2.Final/weld-core-1.1.2.Final.jar:/home/gross/.m2/repository/com/google/guava/guava/r06/guava-r06.jar:/home/gross/.m2/repository/org/jboss/spec/javax/interceptor/jboss-interceptors-api_1.1_spec/1.0.0.Beta1/jboss-interceptors-api_1.1_spec-1.0.0.Beta1.jar:/home/gross/.m2/repository/org/jboss/interceptor/jboss-interceptor-spi/2.0.0.CR1/jboss-interceptor-spi-2.0.0.CR1.jar:/home/gross/.m2/repository/org/jboss/interceptor/jboss-interceptor-core/2.0.0.CR1/jboss-interceptor-core-2.0.0.CR1.jar:/home/gross/.m2/repository/org/slf4j/slf4j-ext/1.5.10/slf4j-ext-1.5.10.jar:/home/gross/.m2/repository/ch/qos/cal10n/cal10n-api/0.7.2/cal10n-api-0.7.2.jar:/home/gross/.m2/repository/javax/el/el-api/2.2/el-api-2.2.jar:/home/gross/.m2/repository/javax/enterprise/cdi-api/1.0-SP4/cdi-api-1.0-SP4.jar:/home/gross/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar:/home/gross/.m2/repository/org/jboss/resteasy/resteasy-jaxb-provider/2.2.2.GA/resteasy-jaxb-provider-2.2.2.GA.jar:/home/gross/.m2/repository/com/sun/xml/bind/jaxb-impl/2.2.4/jaxb-impl-2.2.4.jar:/home/gross/.m2/repository/javax/xml/bind/jaxb-api/2.2.3/jaxb-api-2.2.3.jar:/home/gross/.m2/repository/javax/xml/stream/stax-api/1.0/stax-api-1.0.jar:/home/gross/.m2/repository/com/sun/xml/stream/sjsxp/1.0.1/sjsxp-1.0.1.jar:/home/gross/.m2/repository/org/jboss/resteasy/resteasy-jettison-provider/2.2.2.GA/resteasy-jettison-provider-2.2.2.GA.jar:/home/gross/.m2/repository/org/codehaus/jettison/jettison/1.2/jettison-1.2.jar:/opt/idea/lib/idea_rt.jar com.intellij.rt.execution.application.AppMain org.jboss.weld.environment.se.StartMain {quote} I think, it's dependencies interfere problem, but haven't yet found the solution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

11
43
0 / 0

[JBoss JIRA] (WELD-994) Passivating Beans do not allow Injection of non-serializable Instance injections

by Cody Lerum (Created) (JIRA)

Passivating Beans do not allow Injection of non-serializable Instance injections -------------------------------------------------------------------------------- Key: WELD-994 URL: https://issues.jboss.org/browse/WELD-994 Project: Weld Issue Type: Bug Environment: AS 7.0.2 WELD-000900 1.1.2 (Final) Reporter: Cody Lerum Given the following Code {code:java} @ConversationScoped @Named public class EmailTester implements Serializable { private static final long serialVersionUID = 1L; @Inject private Instance<MailMessage> mailMessage; @Inject private ActiveUser activeUser; @Inject private Messages messages; @Inject private Instance<Session> session; public void send() { MailMessage m = mailMessage.get(); m.from(activeUser.getUser()); m.to(activeUser.getUser()); m.subject("test"); m.bodyText("Blah blah blah"); m.send(session.get()); messages.info("Message Sent"); } } {code} Weld throws org.jboss.weld.exceptions.IllegalProductException: WELD-000054 Producers cannot produce non-serializable instances for injection into non-transient fields of passivating beans\\n\\nProducer\: Producer Method [Session] with qualifiers [@Any @Default] declared as [[method] @Produces @ExtensionManaged public org.jboss.seam.mail.core.MailSessionProducer.getMailSession(MailConfig)]\\nInjection Point\: org.jboss.weld.bean.builtin.InstanceImpl$InstanceInjectionPoint@2146ca: javax.faces.FacesException: #{emailTester.send()}: org.jboss.weld.exceptions.IllegalProductException: WELD-000054 Producers cannot produce non-serializable instances for injection into non-transient fields of passivating beans\\n\\nProducer\: Producer Method [Session] with qualifiers [@Any @Default] declared as [[method] @Produces @ExtensionManaged public org.jboss.seam.mail.core.MailSessionProducer.getMailSession(MailConfig)]\\nInjection Point\: org.jboss.weld.bean.builtin.InstanceImpl$InstanceInjectionPoin! t@2146ca Since a new instance is returned each time a get() is called it should not matter that the javax.mail.Session is not non-serializable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

8
11
0 / 0

[JBoss JIRA] Created: (WELD-909) Dual faces mapping and cid parameter for conversational redirect

by Nicklas Karlsson (JIRA)

Dual faces mapping and cid parameter for conversational redirect ---------------------------------------------------------------- Key: WELD-909 URL: https://issues.jboss.org/browse/WELD-909 Project: Weld Issue Type: Bug Components: Conversations Affects Versions: 1.1.1.Final Reporter: Nicklas Karlsson Given a page like {code} <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core"> <h:head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /> <title>Concept</title> </h:head> <h:body> <f:view> <h:form> <h:commandButton value="redirect" action="page?faces-redirect=true"/> <h:commandButton value="non-transient" action="#{backingBean.nonTransient}"/> </h:form> </f:view> </h:body> </html> {code} and a backing bean like {code} package fi.nik.concept; import javax.enterprise.context.Conversation; import javax.inject.Inject; import javax.inject.Named; @Named public class BackingBean { @Inject private Conversation conversation; public String nonTransient() { conversation.begin(); return "page?faces-redirect=true"; } } {code} clicking "redirect" with non-transient conversations work fine but clicking "non-transient" duplicates the faces mappings and cid to something like http://localhost:8080/concept/faces/faces/page.xhtml?cid=1&cid=1 and clicking "redirect" after keeps the URL like that. It works normally after that (since the faces mapping is still hit and the cid is repeated with the same value) but it looks a bit odd. Would have written a test for it but git on Windows is... a bit nonlinear at times. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

5
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues March 2012