January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing

by Alexander Sparkowsky (JIRA)

[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ] Alexander Sparkowsky commented on WFLY-2387: -------------------------------------------- I have been able to use the following workaround on WildFly 9.0.2 {code:java} protected String getPrincipalName() { // Try to get `Principal` via CDI workaround [WFLY-2387](https://issues.jboss.org/browse/WFLY-2387) final Instance<Principal> principalInstance = CDI.current().select(Principal.class); Principal principal = null; // Set default principalName String principalName = "<none>"; if (principalInstance != null && !principalInstance.isUnsatisfied() && !principalInstance.isAmbiguous() && (principal = principalInstance.get()) != null) { principalName = principal.getName(); } return principalName; } {code} > 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

1
0
0 / 0

[JBoss JIRA] (WFLY-5822) Clustering performance regression in ejbremote-dist-sync scenario

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-5822?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on WFLY-5822: ------------------------------------------- The ejbservlet stress test scenario exercises SFSBs in a similar way as ejbremote, but uses servlet requests instead of EJBClient requests to access the beans on the server. We have done a run of the ejbservlet performance test for EAP6 and EAP7 using dist sync with two cluster nodes instead of four (due to low current availability in the performance lab). The results also show a regression of EAP7 with respect to EAP6: http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-6x-stres... http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-stres... In EAP 6, the max throughput hits 8.5k requests at 2400 clients and more or less levels out, whereas EAP7 hits a max of about 6k requests at 800 clients and then flatlines. > Clustering performance regression in ejbremote-dist-sync scenario > ------------------------------------------------------------------ > > Key: WFLY-5822 > URL: https://issues.jboss.org/browse/WFLY-5822 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 10.0.0.CR5 > Reporter: Michal Vinkler > Assignee: Richard Achmatowicz > Priority: Critical > > Compared to EAP 6, all SYNC scenarios have the same/better performance except of this one, wonder why? > Compare these results: > stress-ejbremote-dist-sync > 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...] > 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...] > --------------------------------------- > Just for comparison: ejbremote REPL_SYNC scenario *performs well* on the other hand: > stress-ejbremote-repl-sync > 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...] > 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1309) Applying patch - "no space available" not specific enough

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1309?page=com.atlassian.jira.plugi... ] Tomas Hofman moved JBEAP-2882 to WFCORE-1309: --------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1309 (was: JBEAP-2882) Workflow: GIT Pull Request workflow (was: CDW v1) Component/s: Patching (was: Patching) Target Release: (was: 7.0.0.GA) Affects Version/s: 2.0.7.Final (was: 7.0.0.ER3) > Applying patch - "no space available" not specific enough > --------------------------------------------------------- > > Key: WFCORE-1309 > URL: https://issues.jboss.org/browse/WFCORE-1309 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 2.0.7.Final > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > Copy of https://bugzilla.redhat.com/show_bug.cgi?id=1299160: > Patch apply can fail if there is not enough free space, however the message does not indicate what device does not have any free space. Users assume there is not enough free space on the drive where the JBoss install they are applying the patch to, however it appears this may or may not be the case. > Patch apply uses tmp space and if there is not enough tmp space it will fail with this message as well. The message should be more explicit as to where there is no space so that the user knows which drive to check. > [disconnected /] patch apply /path/to/jboss-eap-6.2.4-patch.zip > java.io.IOException: No space left on device -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6030) Undertow 1.3.14.Final

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6030?page=com.atlassian.jira.plugin.... ] Stuart Douglas moved JBEAP-2878 to WFLY-6030: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6030 (was: JBEAP-2878) Workflow: GIT Pull Request workflow (was: CDW v1) > Undertow 1.3.14.Final > --------------------- > > Key: WFLY-6030 > URL: https://issues.jboss.org/browse/WFLY-6030 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Stuart Douglas > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-868) CLI if/else is not handling special characters strings with parenthesis

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-868?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-868: ------------------------------------------------ Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1249773|https://bugzilla.redhat.com/show_bug.cgi?id=1249773] from ON_QA to VERIFIED > CLI if/else is not handling special characters strings with parenthesis > ----------------------------------------------------------------------- > > Key: WFCORE-868 > URL: https://issues.jboss.org/browse/WFCORE-868 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.0.0.Alpha12 > Reporter: Tomas Hofman > Assignee: Alexey Loubyansky > Fix For: 2.0.0.Beta7 > > > When using CLI if-else scripting that uses a string that contains parenthesis it fails with the following message: > Failed to handle 'if (outcome == success && result.value != "a64180c0)e7187af86b435229de904104") of /system-property=test:read-resource': Unexpected operation at 49 in '(outcome == success && result.value != "a64180c0)e7187af86b435229de904104")' -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5995) Initial calculation of the first expiration time for a scheduled timer is wrong if a start date is set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5995?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-5995: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1298651, https://bugzilla.redhat.com/show_bug.cgi?id=1299882 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1298651) > Initial calculation of the first expiration time for a scheduled timer is wrong if a start date is set > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-5995 > URL: https://issues.jboss.org/browse/WFLY-5995 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.2.1.Final, 9.0.2.Final, 10.0.0.CR5 > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Labels: timers, timerservice > > If a scheduled timer should be created with the following parameters: > ScheduleExpression[second=0 minute=0/5 hour=20-22 dayOfWeek=* dayOfMonth=* month=* year=* start=Thu Jan 14 09:45:35 GMT+1 2016] > The first schedule should be > Thu Jan 17 20:00:20 GMT+1 2016 > but is calculated as > Sun Jan 17 20:45:35 GMT+1 2016 > The minutes are not correctly set according to the schedule and the given start date. > This happen for seconds/minutes if the ScheduleExpression limit the range. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6029) Upgrade JBossWS from 5.1.2.Final to 5.1.3.Final

by Alessio Soldano (JIRA)

Alessio Soldano created WFLY-6029: ------------------------------------- Summary: Upgrade JBossWS from 5.1.2.Final to 5.1.3.Final Key: WFLY-6029 URL: https://issues.jboss.org/browse/WFLY-6029 Project: WildFly Issue Type: Component Upgrade Components: Web Services Affects Versions: 10.0.0.CR5 Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: 10.0.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1605) API changes

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1605?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1605: --------------------------- Description: API changes to be done in 4.0, which break code: * MessageDispatcher: remove MessageListener * Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH * Remove @Deprecated methods, properties or classes * Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once) * Make {{RspFilter}} --> {{RspFilter<T>}} * {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class. * Request<T> * RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps was: API changes to be done in 4.0, which break code: * MessageDispatcher: remove MessageListener * Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH * Remove @Deprecated methods, properties or classes * Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once) * Make {{RspFilter}} --> {{RspFilter<T>}} * {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class. * Request<T> > API changes > ----------- > > Key: JGRP-1605 > URL: https://issues.jboss.org/browse/JGRP-1605 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > API changes to be done in 4.0, which break code: > * MessageDispatcher: remove MessageListener > * Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH > * Remove @Deprecated methods, properties or classes > * Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once) > * Make {{RspFilter}} --> {{RspFilter<T>}} > * {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class. > * Request<T> > * RpcDispatcher: only 1 Marshaller, not separate ones for reqs and rsps -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2005) Probe: more detailed information about RPCs

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2005?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2005: -------------------------------- RPCs which return _futures_ are hard to time, as we would have to change the code which receives the response(s). I therefore picked the simple way out, which is to count them as _async_ RPCs... > Probe: more detailed information about RPCs > ------------------------------------------- > > Key: JGRP-2005 > URL: https://issues.jboss.org/browse/JGRP-2005 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.8 > > > {{probe.sh rpcs}} currently only returns the number of multicasts, anycasts and unicasts (async and sync) since the last reset. Add 3 additional keys: > * rpcs-enable-details: captures detailed information from now on. This is not enabled by default as capturing this information is costly (hashmap put/get, timing of RPCs etc) > * rpcs-disable-details: disables capturing of details > * rpcs-details: dumps detailed information (needs to be enabled before) > ** For async RPCs: number of RPCs for every destination (unicast or multicast) > ** For sync RPCs: ditto, plus min/max/avg invocation times -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1012) kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1012?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on DROOLS-1012: ------------------------------------------------- Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1293455|https://bugzilla.redhat.com/show_bug.cgi?id=1293455] from ON_QA to VERIFIED > kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry > ------------------------------------------------------------------------------------- > > Key: DROOLS-1012 > URL: https://issues.jboss.org/browse/DROOLS-1012 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.4.x > > Attachments: brms-fuse-integration-master.tgz > > > kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry. This implies that when the KieContainer is created in a OSGi environment it is not able to get an instance of the MavenClassLoaderResolver and then cannot create a ClassLoader including all the transitive dependencies of the kjar to be compiled. > The attached project reproduces this issue. In order to run it, it's enough to do a mvn clean install of the project and issue the following commands in fuse: > features:addurl mvn:com.redhat/brms-fuse-integration-features/0.0.1-SNAPSHOT/xml/features > features:install brms-integration-bundle -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016