May 2011 - seam-issues - Jboss List Archives

[JBoss JIRA] Created: (SEAMCATCH-41) Provide SPI for registering HandlerMethod programatically

by Jozef Hartinger (JIRA)

Provide SPI for registering HandlerMethod programatically --------------------------------------------------------- Key: SEAMCATCH-41 URL: https://issues.jboss.org/browse/SEAMCATCH-41 Project: Seam Catch Issue Type: Feature Request Components: Framework Integration Affects Versions: 3.0.0.Beta1 Reporter: Jozef Hartinger Assignee: Jason Porter It would be nice to offer registerHandlerMethod(HandlerMethod<?> method) for other modules to be able to register handler methods. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
6
0 / 0

[JBoss JIRA] Created: (SEAMCATCH-50) Interceptor that propagates exceptions

by Nicklas Karlsson (JIRA)

Interceptor that propagates exceptions -------------------------------------- Key: SEAMCATCH-50 URL: https://issues.jboss.org/browse/SEAMCATCH-50 Project: Seam Catch Issue Type: Feature Request Reporter: Nicklas Karlsson Assignee: Jason Porter A simple CDI interceptor that catches everything the execution throws and fires an exception handling event for them. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
7
0 / 0

[JBoss JIRA] Created: (SEAMVALIDATE-18) ValidationExtension conflicts with Weld build-in Validator

by Jan Groth (JIRA)

ValidationExtension conflicts with Weld build-in Validator ---------------------------------------------------------- Key: SEAMVALIDATE-18 URL: https://issues.jboss.org/browse/SEAMVALIDATE-18 Project: Seam Validation Issue Type: Bug Reporter: Jan Groth Assignee: Gunnar Morling I'm on a project with the full Seam 3 stack, and using @Inject private Validator validator; results in a deployment exception: WELD-001318 Cannot resolve an ambiguous dependency between [ org.jboss.seam.validation.ValidationExtension$2@38f8cf74, Built-in Bean [javax.validator.Validator] with qualifiers [@Default] ] I suspect the following code from ValidationException.java to be unaware of the Weld built-in component "javax.validator.Validator": // do nothing, if Validator already exists if (!bm.getBeans(Validator.class).isEmpty()) { return; } If the code gets executed, it works fine, but it seems as if the Weld-Component gets installed _after ValidationExtension registers its validator... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

5
9
0 / 0

[JBoss JIRA] Created: (SOLDER-106) Seam transaction potential memory leaks if there is nested @TransactionAttritue

by yangju (JIRA)

Seam transaction potential memory leaks if there is nested @TransactionAttritue ------------------------------------------------------------------------------- Key: SOLDER-106 URL: https://issues.jboss.org/browse/SOLDER-106 Project: Seam Solder Issue Type: Bug Affects Versions: 3.0.0.Final Environment: Windows, Eclipse, jboss AS 6 Final Reporter: yangju I have been doing some performance testing on cdi beans with @TransactionAttribute in jboss AS 6 final. After my application runs non-stop for a while (I have created 10 threads constantly invoking the ApplicaitonScoped bean to get data from database and then update those data), I got got exception:: java.lang.OutOfMemoryError: GC overhead limit exceeded. This happened when I have Bean A injects Bean B and both A and B are annotated with @TransactionAttribute. These two beans looks up (instead of injecting) entity manager from an entity manager factory (jndi lookup emf first, then emf.createEntityManager()). These beans are not declared as session bean and no SMPC is used. I thought transaction will be propagated from one bean to another, or it only does that for stateful session beans or SMPC? If I remove one of the TransactionAttribute annotation from B then the OOM problem does not occur. This OOM problem also occurs after my application runs for a while in this scenario: Bean A injects Bean B and Bean C; Bean C injects Bean B. I analyzed the heap dump with eclipse memory analyzer and it suspects that the seam 3 transaction interceptor might have memory leaks. I used Eclipse Memory Analyzer to analyze the heap dump when OOM occurred. It says: One instance of "org.jboss.weld.context.CreationalContextImpl" loaded by "org.jboss.classloader.spi.base.BaseClassLoader @ 0xd2b85a08" occupies 387,677,848 (40.99%) bytes. The memory is accumulated in one instance of "java.lang.Object[]" loaded by "<system class loader>". Keywords java.lang.Object[] org.jboss.classloader.spi.base.BaseClassLoader @ 0xd2b85a08 org.jboss.weld.context.CreationalContextImpl Shortest Paths To the Accumulation Point Class Name Shallow Heap Retained Heap java.lang.Object[198578] @ 0xf2c419b8 1,588,648 387,677,288 elementData java.util.ArrayList @ 0xde867580 40 387,677,328 list, c java.util.Collections$SynchronizedRandomAccessList @ 0xde867568 40 387,677,368 dependentInstances org.jboss.weld.context.CreationalContextImpl @ 0xde867418 48 387,677,848 creationalContext org.jboss.weld.bean.builtin.InstanceImpl @ 0xde8673e0 56 88 transaction org.jboss.seam.transaction.TransactionInterceptor @ 0xde867330 40 584 instance org.jboss.interceptor.proxy.InterceptorInvocation$InterceptorMethodInvocation @ 0xfc2cf5a8 40 80 [0] java.lang.Object[10] @ 0xfc2cf570 104 184 elementData java.util.ArrayList @ 0xfc2cf558 40 224 interceptorMethodInvocations org.jboss.interceptor.proxy.SimpleInterceptionChain @ 0xfc2cf530 64 984 <Java Local> java.lang.Thread @ 0xdef53810 pool-109-thread-2 Thread 176 44,120 value java.util.HashMap$Entry @ 0xde867310 » 48 48 Total: 2 entries -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
5
0 / 0

[JBoss JIRA] Created: (SEAMPERSIST-44) remove annotation @Remove from o.j.st.TransactionManagerSynchronizations

by Denis Forveille (JIRA)

remove annotation @Remove from o.j.st.TransactionManagerSynchronizations ------------------------------------------------------------------------ Key: SEAMPERSIST-44 URL: https://issues.jboss.org/browse/SEAMPERSIST-44 Project: Seam Persistence Issue Type: Bug Affects Versions: 3.0.0.CR3 Environment: WebSphere v8 beta Reporter: Denis Forveille org.jboss.seam.transaction.TransactionManagerSynchronizations contains an annotaion @Remove but this class in not a SFSB.. This causes the following exception in WebShere v8 beta {noformat}An exception occurred while validating an annotation: com.ibm.wsspi.amm.validate.ValidationException: CWWAM2102E: The @Remove annotation is defined for bean org.jboss.seam.transaction.TransactionManagerSynchronizations; however, it is only applicable to a stateful session bean class. {noformat} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (SEAMFACES-47) UIInputContainer keeps invalid state too long

by Nicklas Karlsson (JIRA)

UIInputContainer keeps invalid state too long --------------------------------------------- Key: SEAMFACES-47 URL: https://jira.jboss.org/browse/SEAMFACES-47 Project: Seam Faces Issue Type: Bug Components: UI Components Affects Versions: 3.0.0.Alpha3 Reporter: Nicklas Karlsson Given a <p:input> <h:inputText value="#{credentials.username}" /> </p:input> <p:input> <h:inputText value="#{credentials.password}" /> </p:input> <h:commandButton value="Login" action="#{credentials.login}" /> and a @Model public class Credentials { @NotNull private String username; public String getUsername() { return username; } public void setUsername(String username) { this.username = username; } @NotNull public String getPassword() { return password; } public void setPassword(String password) { this.password = password; } private String password; public void login() { System.out.println(username); System.out.println(password); } } with <context-param> <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name> <param-value>true</param-value> </context-param> and a modified input.xhtml that outputs #{cc.attrs.invalid} you submit a blank form and get "true" and correct message for both fields, then you enter a value in the second field and re-submit and the messages are correct but both fields still show true for the invalid attribute output (making it impossible to use the attr for rendered attributes if e.g. an error image) -- 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

13 years, 6 months

5
4
0 / 0

[JBoss JIRA] Created: (SEAMJCR-12) API for injecting Credentials

by John Ament (JIRA)

API for injecting Credentials ----------------------------- Key: SEAMJCR-12 URL: https://issues.jboss.org/browse/SEAMJCR-12 Project: Seam JCR Issue Type: Feature Request Components: CDI & Injection API Reporter: John Ament Assignee: John Ament Fix For: 3.0.0.Alpha2 We should support injecting credentials to the backend frameworks when producing sessions. The requirement should be conditional and should end up scoped to the same context as is being injected into. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (SEAMSECURITY-44) security-openid-op - ambiguous bean names

by Jozef Hartinger (JIRA)

security-openid-op - ambiguous bean names ----------------------------------------- Key: SEAMSECURITY-44 URL: https://issues.jboss.org/browse/SEAMSECURITY-44 Project: Seam Security Issue Type: Bug Environment: GlassFish 3.1 + Weld SNAPSHOT Reporter: Jozef Hartinger [#|2011-03-24T10:57:47.967+0100|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=67;_ThreadName=Thread-1;|Exception while loading the app : WELD-001414 Bean name is ambiguous. Name identity resolves to beans [Managed Bean [class org.jboss.seam.security.examples.openid.Identity] with qualifiers [@Any @Default @Named], Managed Bean [class org.jboss.seam.security.IdentityImpl] with qualifiers [@Any @Default @Named]] org.jboss.weld.exceptions.DeploymentException: WELD-001414 Bean name is ambiguous. Name identity resolves to beans [Managed Bean [class org.jboss.seam.security.examples.openid.Identity] with qualifiers [@Any @Default @Named], Managed Bean [class org.jboss.seam.security.IdentityImpl] with qualifiers [@Any @Default @Named]] at org.jboss.weld.bootstrap.Validator.validateBeanNames(Validator.java:480) at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:376) at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:396) at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:190) at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128) at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:298) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370) at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235) at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:465) at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:222) at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168) at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

4
3
0 / 0

[JBoss JIRA] Created: (SEAMSERVLET-34) Migrate to Arquillian 1.0.0.Alpha5

by Jozef Hartinger (JIRA)

Migrate to Arquillian 1.0.0.Alpha5 ---------------------------------- Key: SEAMSERVLET-34 URL: https://issues.jboss.org/browse/SEAMSERVLET-34 Project: Seam Servlet Issue Type: Task Components: Build Infrastructure Affects Versions: 3.0.0.Final Reporter: Jozef Hartinger Assignee: Jozef Hartinger Fix For: 3.0.1.Beta1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
3
0 / 0

[JBoss JIRA] Created: (SEAMJCR-16) Repository resolver behavior

by John Ament (JIRA)

Repository resolver behavior ---------------------------- Key: SEAMJCR-16 URL: https://issues.jboss.org/browse/SEAMJCR-16 Project: Seam JCR Issue Type: Feature Request Components: CDI & Injection API Affects Versions: 3.0.0.Alpha1 Reporter: John Ament Fix For: 3.0.0.Alpha2 Repository resolver - support direct injection for modeshape, exo, jackrabbit, etc, JCR implementations. Allow qualifiers that can resolve a Map as the same type to look up the repository and session. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues May 2011