[JBoss JIRA] (WFCORE-1319) Suggested defaults for Metasize and Java 8
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1319?page=com.atlassian.jira.plugi... ]
Ken Wills commented on WFCORE-1319:
-----------------------------------
[~andy.miller] Andrig, thanks for your input. What is your opinion on the setting for servers in the <jvm> section of host.xml? We used to use 256m for permgen, but using this for Metaspace appears to cause server processes that are about 100mb bigger than previously. Do you think we could have this set to 128mb?
> Suggested defaults for Metasize and Java 8
> ------------------------------------------
>
> Key: WFCORE-1319
> URL: https://issues.jboss.org/browse/WFCORE-1319
> Project: WildFly Core
> Issue Type: Enhancement
> Reporter: Ken Wills
> Assignee: Ken Wills
>
> Since PermGen is no longer used, and has been replaced by Metasize, we probably need to alter the initial startup values. Current WF is using:
> -XX:MaxMetaspaceSize=256m
> After some testing with garbage collection logging on (\-verbose:gc \-Xloggc:hcgc.log \-XX:+PrintGCDateStamps \-XX:MetaspaceSize=XX), the GC logs were monitored for at least one occurrence of a full GC due to Metadata threshold (example [Full GC (Metadata GC Threshold) 39592K->20187K). Using this information, minimum levels of Metasize for various configurations were determined.
> The numbers below are the values used for \-XX:MetaspaceSize=XXM followed by the number of full GCs triggered at that amount measured during boot of WF10-full:
> Standalone:
> {quote}
> standalone.xml 52MB(1), 53MB(0)
> standalone-full.xml 64MB(1), 65MB(0)
> standalone-ha.xml 52MB(1), 54MB(0)
> standalone-full-ha.xml 79MB(1), 80MB(0)
> {quote}
> For domain mode, the corresponding values were determined to be:
> {quote}
> Process Controller: 12MB(1), 13MB(0)
> Host Controller: 39MB(1), 40MB(0)
> {quote}
> In domain mode, a very slight, non-scientifically measured boot time difference was observed (1769ms default Metasize vs 1694ms with 40m MetaSize set for host controller).
> The approximate cost of increasing MetaSize over the default is summerized below (using top to collect RSS after server boot):
> JBoss AS 7.1.1: (default permgen (-XX:PermSize=256m -XX:MaxPermSize=256m), JDK 7)
> ||Configuration||RSS(KB)||
> |standalone.xml| 182,652 |
> |standalone-ha.xml | 211,672 |
> |standalone-full.xml | 217,636 |
> |standalone-full-ha.xml | 289,524 |
> |domain:||
> | Server-one: | 227,220 |
> | Server-two: | 234,944 |
> | PC: | 37,584 |
> | HC: | 138,428 |
> Wildfly 10: (default Metasize == 21M)
> ||Configuration||RSS(KB)||
> |standalone.xml | 293,576 |
> |standalone-ha.xml | 303,344 |
> |standalone-full.xml | 388,660 |
> |standalone-full-ha.xml | 478,576 |
> |domain: ||
> | Server-one: | 379,076 |
> | Server-two: | 377,516 |
> | PC: | 55,000 |
> | HC: | 272,120 |
> Wildfly 10: (Metasize == 64M)
> |standalone.xml | 290,236 |
> |standalone-ha.xml | 306,032 |
> |standalone-full.xml | 396,596 |
> |standalone-full-ha.xml | 501,576 |
> |domain:|
> | Server-one: |
> | Server-two: |
> | PC: |
> | HC: |
> Wildfly 10: (Metasize == 96M)
> ||Configuration||RSS(KB)||
> |standalone.xml |317,996 |
> |standalone-ha.xml | 306,516 |
> |standalone-full.xml |416,008 |
> |standalone-full-ha.xml |460,952 |
> |domain: |
> | Server-one: | 380,816 |
> | Server-two: | 374,300 |
> | PC: | 55,308 |
> | HC: | 273,220 |
> Additional measurements. Using just Wildfly-core, the following RSS sizes are measured for the indicated Metasize:
> Wildfly-10 Core master
> ||Metasize || RSS(KB) ||
> |21m | 117,760|
> |64m | 120,772|
> |96m | 131,104|
> There is little boot time impact on the change:
> Wildfly-10 Core master
> ||Metasize || Boot time (MS) ||
> |21m | 2127 |
> |64m | 2066 |
> |96m | 2099 |
> Based on the memory impact of defaulting to 96M (approx 30mb initially over the default value of 21mb), it would seem to make sense to use this as a default value, which allows maintaining boot times without incurring a full GC due to Metasize and provides enough initial Metasize to both start the application server and perhaps deploy an application without incurring any performance penalty.
> An additional note: host*.xml has JVM params set to MetaspaceSize=256m, which is probably too large an initial value.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1323) Change org.slf4j.jcl-over-slf4j from public to private
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1323?page=com.atlassian.jira.plugi... ]
James Perkins moved JBEAP-2981 to WFCORE-1323:
----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1323 (was: JBEAP-2981)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Modules
(was: Modules)
Target Release: (was: 7.0.0.GA)
> Change org.slf4j.jcl-over-slf4j from public to private
> ------------------------------------------------------
>
> Key: WFCORE-1323
> URL: https://issues.jboss.org/browse/WFCORE-1323
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules
> Reporter: James Perkins
> Assignee: James Perkins
>
> Currently this module is used as an alias for {{org.apache.commons.logging}}. A change to the {{org.apache.commons.logging}} will be required to make it a delegate module rather than an alias.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1322) Change org.jboss.log4j.logmanger from public to private
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1322?page=com.atlassian.jira.plugi... ]
James Perkins moved JBEAP-2979 to WFCORE-1322:
----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1322 (was: JBEAP-2979)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Modules
(was: Modules)
> Change org.jboss.log4j.logmanger from public to private
> -------------------------------------------------------
>
> Key: WFCORE-1322
> URL: https://issues.jboss.org/browse/WFCORE-1322
> Project: WildFly Core
> Issue Type: Task
> Components: Modules
> Reporter: James Perkins
> Assignee: James Perkins
>
> Currently this module is used as an alias for {{org.apache.log4j}}. A change to the {{org.apache.log4j}} will be required to make it a delegate module rather than an alias.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1319) Suggested defaults for Metasize and Java 8
by Andrig Miller (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1319?page=com.atlassian.jira.plugi... ]
Andrig Miller commented on WFCORE-1319:
---------------------------------------
I also concur. The 96M looks like the sensible default. In the performance lab we remove these settings anyway, so this really to support those memory constrained environments to begin with. If your using an 8, 12, 16 or even larger heap, your usually not worried about the meta space.
So, let's run with this.
> Suggested defaults for Metasize and Java 8
> ------------------------------------------
>
> Key: WFCORE-1319
> URL: https://issues.jboss.org/browse/WFCORE-1319
> Project: WildFly Core
> Issue Type: Enhancement
> Reporter: Ken Wills
> Assignee: Ken Wills
>
> Since PermGen is no longer used, and has been replaced by Metasize, we probably need to alter the initial startup values. Current WF is using:
> -XX:MaxMetaspaceSize=256m
> After some testing with garbage collection logging on (\-verbose:gc \-Xloggc:hcgc.log \-XX:+PrintGCDateStamps \-XX:MetaspaceSize=XX), the GC logs were monitored for at least one occurrence of a full GC due to Metadata threshold (example [Full GC (Metadata GC Threshold) 39592K->20187K). Using this information, minimum levels of Metasize for various configurations were determined.
> The numbers below are the values used for \-XX:MetaspaceSize=XXM followed by the number of full GCs triggered at that amount measured during boot of WF10-full:
> Standalone:
> {quote}
> standalone.xml 52MB(1), 53MB(0)
> standalone-full.xml 64MB(1), 65MB(0)
> standalone-ha.xml 52MB(1), 54MB(0)
> standalone-full-ha.xml 79MB(1), 80MB(0)
> {quote}
> For domain mode, the corresponding values were determined to be:
> {quote}
> Process Controller: 12MB(1), 13MB(0)
> Host Controller: 39MB(1), 40MB(0)
> {quote}
> In domain mode, a very slight, non-scientifically measured boot time difference was observed (1769ms default Metasize vs 1694ms with 40m MetaSize set for host controller).
> The approximate cost of increasing MetaSize over the default is summerized below (using top to collect RSS after server boot):
> JBoss AS 7.1.1: (default permgen (-XX:PermSize=256m -XX:MaxPermSize=256m), JDK 7)
> ||Configuration||RSS(KB)||
> |standalone.xml| 182,652 |
> |standalone-ha.xml | 211,672 |
> |standalone-full.xml | 217,636 |
> |standalone-full-ha.xml | 289,524 |
> |domain:||
> | Server-one: | 227,220 |
> | Server-two: | 234,944 |
> | PC: | 37,584 |
> | HC: | 138,428 |
> Wildfly 10: (default Metasize == 21M)
> ||Configuration||RSS(KB)||
> |standalone.xml | 293,576 |
> |standalone-ha.xml | 303,344 |
> |standalone-full.xml | 388,660 |
> |standalone-full-ha.xml | 478,576 |
> |domain: ||
> | Server-one: | 379,076 |
> | Server-two: | 377,516 |
> | PC: | 55,000 |
> | HC: | 272,120 |
> Wildfly 10: (Metasize == 64M)
> |standalone.xml | 290,236 |
> |standalone-ha.xml | 306,032 |
> |standalone-full.xml | 396,596 |
> |standalone-full-ha.xml | 501,576 |
> |domain:|
> | Server-one: |
> | Server-two: |
> | PC: |
> | HC: |
> Wildfly 10: (Metasize == 96M)
> ||Configuration||RSS(KB)||
> |standalone.xml |317,996 |
> |standalone-ha.xml | 306,516 |
> |standalone-full.xml |416,008 |
> |standalone-full-ha.xml |460,952 |
> |domain: |
> | Server-one: | 380,816 |
> | Server-two: | 374,300 |
> | PC: | 55,308 |
> | HC: | 273,220 |
> Additional measurements. Using just Wildfly-core, the following RSS sizes are measured for the indicated Metasize:
> Wildfly-10 Core master
> ||Metasize || RSS(KB) ||
> |21m | 117,760|
> |64m | 120,772|
> |96m | 131,104|
> There is little boot time impact on the change:
> Wildfly-10 Core master
> ||Metasize || Boot time (MS) ||
> |21m | 2127 |
> |64m | 2066 |
> |96m | 2099 |
> Based on the memory impact of defaulting to 96M (approx 30mb initially over the default value of 21mb), it would seem to make sense to use this as a default value, which allows maintaining boot times without incurring a full GC due to Metasize and provides enough initial Metasize to both start the application server and perhaps deploy an application without incurring any performance penalty.
> An additional note: host*.xml has JVM params set to MetaspaceSize=256m, which is probably too large an initial value.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1030) Nullpointer in JpaTimerJobInstance.call on startup
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1030?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1030:
-------------------------------------
Reproduce with the following test class
{code}
package org.drools.persistence.session;
import org.drools.persistence.util.PersistenceUtil;
import org.junit.After;
import org.junit.Before;
import org.junit.Ignore;
import org.junit.Test;
import org.kie.api.KieBaseConfiguration;
import org.kie.api.conf.EventProcessingOption;
import org.kie.api.definition.type.Expires;
import org.kie.api.definition.type.Role;
import org.kie.api.io.ResourceType;
import org.kie.api.runtime.Environment;
import org.kie.api.runtime.rule.EntryPoint;
import org.kie.internal.KnowledgeBase;
import org.kie.internal.KnowledgeBaseFactory;
import org.kie.internal.builder.KnowledgeBuilder;
import org.kie.internal.builder.KnowledgeBuilderFactory;
import org.kie.internal.io.ResourceFactory;
import org.kie.internal.persistence.jpa.JPAKnowledgeService;
import org.kie.internal.runtime.StatefulKnowledgeSession;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import javax.naming.InitialContext;
import javax.transaction.UserTransaction;
import java.io.Serializable;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.UUID;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import static org.drools.persistence.util.PersistenceUtil.DROOLS_PERSISTENCE_UNIT_NAME;
import static org.drools.persistence.util.PersistenceUtil.createEnvironment;
import static org.junit.Assert.fail;
@Ignore
public class JpaPersistentCepSessionTest {
private static ExecutorService executor = Executors.newSingleThreadExecutor();
private static Logger logger = LoggerFactory.getLogger( JpaPersistentCepSessionTest.class );
private HashMap<String, Object> context;
private Environment env;
@Before
public void setUp() throws Exception {
context = PersistenceUtil.setupWithPoolingDataSource( DROOLS_PERSISTENCE_UNIT_NAME );
env = createEnvironment(context);
}
@After
public void tearDown() throws Exception {
PersistenceUtil.cleanUp(context);
}
@Test
public void test1() throws Exception {
KnowledgeBase kbase = getKnowledgeBase( );
UserTransaction ut = (UserTransaction) new InitialContext().lookup( "java:comp/UserTransaction" );
ut.begin();
final StatefulKnowledgeSession ksession = JPAKnowledgeService.newStatefulKnowledgeSession( kbase, null, env );
ut.commit();
EntryPoint entryPoint = ksession.getEntryPoint( "EntryPointA" );
MyEvent e = new MyEvent();
e.setUsers(get());
MySecondEvent event = new MySecondEvent();
event.setType("SomeType");
ut = (UserTransaction) new InitialContext().lookup( "java:comp/UserTransaction" );
ut.begin();
entryPoint.insert(e);
ksession.insert(event);
ut.commit();
executor.execute( new Runnable() {
@Override
public void run() {
ksession.fireAllRules();
}
} );
// ksession.fireAllRules();
Thread.sleep(10000L);
System.out.println("IDENTIFIER = " + ksession.getIdentifier());
}
@Test
public void test2() throws Exception {
long identifier = 19L;
KnowledgeBase kbase = getKnowledgeBase( );
final StatefulKnowledgeSession ksession = JPAKnowledgeService.loadStatefulKnowledgeSession( identifier, kbase, null, env );
MyEvent e = new MyEvent();
e.setUsers(get());
EntryPoint entryPoint = ksession.getEntryPoint("EntryPointA");
UserTransaction ut = (UserTransaction) new InitialContext().lookup( "java:comp/UserTransaction" );
ut.begin();
entryPoint.insert(e);
ut.commit();
executor.execute( new Runnable() {
@Override
public void run() {
ksession.fireAllRules();
}
} );
Thread.sleep(10000L);
}
public KnowledgeBase getKnowledgeBase( ) {
String str =
"import " + MyEvent.class.getCanonicalName() + "\n" +
"import " + MyModel.class.getCanonicalName() + "\n" +
"import " + MySecondEvent.class.getCanonicalName() + "\n" +
"rule \"Rule1\"\n" +
"\n" +
" when\n" +
" MyEvent( $new_users : users) from entry-point \"EntryPointA\";\n" +
" $p : MyModel() from $new_users;\n" +
" then\n" +
" System.out.println(\"Added model: \" + $p);\n" +
" insert( $p );\n" +
" \n" +
"end\n" +
"\n" +
"rule \"Rule2\"\n" +
" \n" +
" when\n" +
" $e : MySecondEvent( type == \"SomeType\");\n" +
" $p : MyModel( processed == false );\n" +
" then\n" +
" System.out.println( $p);\n" +
" $p.setProcessed(true);\n" +
" update($p)\n" +
"end\n";
KieBaseConfiguration kbconf = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
kbconf.setOption( EventProcessingOption.STREAM );
KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
kbuilder.add( ResourceFactory.newByteArrayResource( str.getBytes() ), ResourceType.DRL );
KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(kbconf);
if ( kbuilder.hasErrors() ) {
fail( kbuilder.getErrors().toString() );
}
kbase.addKnowledgePackages( kbuilder.getKnowledgePackages() );
return kbase;
}
public static List<MyModel> get() {
List<MyModel> res = new ArrayList<MyModel>();
for(int i=0; i< 10; i++) {
MyModel m = new MyModel();
m.setName( UUID.randomUUID().toString() );
res.add(m);
}
return res;
}
@Role(Role.Type.EVENT)
@Expires("1m")
public static class MyEvent implements Serializable {
private List<MyModel> users = new ArrayList<MyModel>();
public void setUsers(List<MyModel> users) {
this.users = users;
}
public List<MyModel> getUsers() {
return users;
}
}
@Role(Role.Type.EVENT)
@Expires("1m")
public static class MyModel implements Serializable {
private String name;
private boolean processed;
public void setName(String name) {
this.name = name;
}
public String getName() {
return name;
}
@Override
public String toString() {
return name;
}
public void setProcessed(boolean processed) {
this.processed = processed;
}
public boolean isProcessed() {
return processed;
}
}
@Role(Role.Type.EVENT)
@Expires("1s")
public static class MySecondEvent implements Serializable {
private String type;
public String getType() {
return type;
}
public void setType(String type) {
this.type = type;
}
}
}
{code}
> Nullpointer in JpaTimerJobInstance.call on startup
> ---------------------------------------------------
>
> Key: DROOLS-1030
> URL: https://issues.jboss.org/browse/DROOLS-1030
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final
> Reporter: Artur Kronenberg
> Assignee: Mario Fusco
> Attachments: test-standalone.zip
>
>
> Hi,
> I have noticed Nullpointer exceptions when I try and reload a persisted session on startup. It is a bit hard to recreate (I am actually not managing it now since I deleted all old sessions to attempt recreation) but I figured maybe someone has an idea. Essentially I am getting this NPE twice:
> java.lang.NullPointerException: null
> at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:50) [drools-persistence-jpa-6.3.0.Final.jar:6.3.0.Final]
> at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:30) [drools-persistence-jpa-6.3.0.Final.jar:6.3.0.Final]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_51]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_51]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_51]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
> When debugging I noticed the following behaviour which points to a race condition:
> If I start my server and try to recreate the session, those NPEs happen 2x.
> If I start my server and put a breakpoint BEFORE creating the CommandService for execution, I can wait for a few seconds and the service can be found.
> It appears that the scheduler's timerJobFactoryManager is not fully there at the time the sessions is being loaded? Or something else is racing with the service creation.
> Is there a way for me to make sure everything is fully instantiated before I use drools? Does a workaround exist? Is this even a bug?
> Thanks and let me know your thoughts. If I run into this again I will attempt to try and reproduce it. Let me know if more info is needed!
> UPDATE:
> I noticed that the reason I can't reproduce it at the moment is that the JpaTimerJobInstance is never called with the newly persisted session. It appears that that timer job depends on something else to happen so that it thinks it needs to start the timerJob
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-2387:
------------------------------------
[~smarlow] You can use {{CDI.current()}} to get a bean instance lazily, i.e. during entity listener callback invocation. In you example, you would have remove the injection points for {{Alpha}} and {{Bravo}} and then do some synchronized lazy init inside {{onEntityCallback()}} invocation. It's definitely not a nice and comfortable way.
> CDI injection in entity listeners failing
> -----------------------------------------
>
> Key: WFLY-2387
> URL: https://issues.jboss.org/browse/WFLY-2387
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading, JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Reporter: Emond Papegaaij
> Assignee: Scott Marlow
> Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml
>
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> at org.jboss.weld.Container.instance(Container.java:65)
> at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> ... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ]
Scott Marlow edited comment on WFLY-2387 at 1/22/16 11:10 AM:
--------------------------------------------------------------
I ran the [https://github.com/tremes/wildfly/tree/WFLY-2387-test] and get failure [https://gist.github.com/scottmarlow/7d2c527442b3f19ca728]
To run this testcase:
{quote}
cd wildfly/testsuite/integration/basic
mvn clean install -Dtest=org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase
{quote}
Why does CDI.current() work around the failure?
What code changes are needed in the [https://github.com/tremes/wildfly/tree/WFLY-2387-test] test case to use the CDI.current workaround?
was (Author: smarlow):
I ran the [https://github.com/tremes/wildfly/tree/WFLY-2387-test] and get failure [https://gist.github.com/scottmarlow/7d2c527442b3f19ca728]
To run this testcase:
{quote}
cd wildfly/testsuite/integration/basic
mvn clean install -Dtest=org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase
{quote}
Why does CDI.current() work around the failure?
What code changes are needed in the [[https://github.com/tremes/wildfly/tree/WFLY-2387-test] test case to use the CDI.current workaround?
> CDI injection in entity listeners failing
> -----------------------------------------
>
> Key: WFLY-2387
> URL: https://issues.jboss.org/browse/WFLY-2387
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading, JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Reporter: Emond Papegaaij
> Assignee: Scott Marlow
> Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml
>
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> at org.jboss.weld.Container.instance(Container.java:65)
> at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> ... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-2387:
------------------------------------
I ran the [https://github.com/tremes/wildfly/tree/WFLY-2387-test] and get failure [https://gist.github.com/scottmarlow/7d2c527442b3f19ca728]
To run this testcase:
{quote}
cd wildfly/testsuite/integration/basic
mvn clean install -Dtest=org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase
{quote}
Why does CDI.current() work around the failure?
What code changes are needed in the [[https://github.com/tremes/wildfly/tree/WFLY-2387-test] test case to use the CDI.current workaround?
> CDI injection in entity listeners failing
> -----------------------------------------
>
> Key: WFLY-2387
> URL: https://issues.jboss.org/browse/WFLY-2387
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading, JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Reporter: Emond Papegaaij
> Assignee: Scott Marlow
> Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml
>
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> at org.jboss.weld.Container.instance(Container.java:65)
> at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> ... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months