[JBoss JIRA] Created: (SEAM-93) Seam3 Booking example NPE in bookHotel on AS7
by Marek Schmidt (JIRA)
Seam3 Booking example NPE in bookHotel on AS7
---------------------------------------------
Key: SEAM-93
URL: https://issues.jboss.org/browse/SEAM-93
Project: Seam 3 Distribution
Issue Type: Bug
Affects Versions: 3.0.0.Final
Environment: jboss-7.0.0.Beta4-SNAPSHOT, build #1194, standalone
Reporter: Marek Schmidt
Assignee: Marek Schmidt
Fix For: Future
Clicking "Book Hotel" on a Hotel Details page leads to javax.ejb.EJBTransactionRolledbackException
{quote}
...
#{bookingAgent.bookHotel}: javax.ejb.EJBTransactionRolledbackException: javax.faces.FacesException: #{bookingAgent.bookHotel}: javax.ejb.EJBTransactionRolledbackException
...
Caused by: java.lang.NullPointerException
at org.jboss.seam.examples.booking.booking.BookingAgent.bookHotel(BookingAgent.java:108) [classes:]
...
{quote}
Seems like bookHotel not run in the same conversation scope for some reason (pretty faces issue, maybe?)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[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
[JBoss JIRA] Created: (SEAMPERSIST-53) Injected EntityManager can not be invoked in java se
by Liu Jianhong (JIRA)
Injected EntityManager can not be invoked in java se
-----------------------------------------------------
Key: SEAMPERSIST-53
URL: https://issues.jboss.org/browse/SEAMPERSIST-53
Project: Seam Persistence
Issue Type: Bug
Affects Versions: 3.0.0.Final
Environment: weld-se-1.1.1,seam-persistence 3.0.0 and 3.0.1-SNAPSHOT
Reporter: Liu Jianhong
When call entityManager.toString(), entityManager.persist() addn so on ,it produces WELD-001303 error:
Exception in thread "main" org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped
at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:664)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:77)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:87)
at org.jboss.seam.transaction.org$jboss$weld$bean-classpath-ManagedBean-org$jboss$seam$transaction$EntityTransaction$@javax$enterprise$context$RequestScoped()@org$jboss$seam$config$xml$core$XmlConfiguredBean()@org$jboss$seam$transaction$DefaultTransaction()${org$jboss$seam$transaction$EntityTransaction$entityManager$@javax$inject$Inject()$$org$jboss$seam$transaction$EntityTransaction$persistenceProvider$@javax$inject$Inject()$$org$jboss$seam$transaction$EntityTransaction$init$@javax$inject$Inject()$(org$jboss$seam$transaction$Synchronizations)$}_$$_WeldClientProxy.isActive(org$jboss$weld$bean-classpath-ManagedBean-org$jboss$seam$transaction$EntityTransaction$@javax$enterprise$context$RequestScoped()@org$jboss$seam$config$xml$core$XmlConfiguredBean()@org$jboss$seam$transaction$DefaultTransaction()${org$jboss$seam$transaction$EntityTransaction$entityManager$@javax$inject$Inject()$$org$jboss$seam$transaction$EntityTransaction$persistenceProvider$@javax$inject$Inject()$$org$jboss$seam$transaction$EntityTransaction$init$@javax$inject$Inject()$(org$jboss$seam$transaction$Synchronizations)$}_$$_WeldClientProxy.java)
at org.jboss.seam.persistence.ManagedPersistenceContextProxyHandler.joinTransaction(ManagedPersistenceContextProxyHandler.java:126)
at org.jboss.seam.persistence.ManagedPersistenceContextProxyHandler.invoke(ManagedPersistenceContextProxyHandler.java:114)
at $Proxy36.toString(Unknown Source)
at java.lang.String.valueOf(String.java:2826)
at java.io.PrintStream.println(PrintStream.java:771)
at test.UserFacet.save(UserFacet.java:27)
at test.Main.main(Main.java:17)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[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, 5 months