[JBoss JIRA] (JGRP-1906) jdbc_ping doesn't delete crashed node
by rama rama (JIRA)
rama rama created JGRP-1906:
-------------------------------
Summary: jdbc_ping doesn't delete crashed node
Key: JGRP-1906
URL: https://issues.jboss.org/browse/JGRP-1906
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.1
Environment: n/a
Reporter: rama rama
Assignee: Bela Ban
Priority: Critical
Hi,
i am having trouble with jgroups. If a node crash, it doesn't get removed from jdbc table.
After 10 hours of work, the table contains 100 rows (that is not a problem) but, when the server start_up, GMS take _AGES_ to try to connect to all this dead node.
Since i am only a 'user' speaking about jgroup and i have no idea on how internally does it work, it this normal?
I don't think so, master of the cluster, or a governor or something like that, should be able to detect if a node is present or not (via FD,VERIFY_SUSPECT) and delete it from JDBC table to avoid issue on startup for the next time, correct me if i am wrong.
Here a copy/paste of my current config, configured in applicative way.
------------------------------------------------------------------------------------
int min_cores = 1;
int max_cores = 50;
InetAddress bind_addr = org.jgroups.util.Util.getAddressByPatternMatch("match-address:" + Config.get("Cluster.bind_addr"));
stack
.addProtocol(new UDP()
.setValue("bind_addr", bind_addr)
.setValue("loopback", true)
.setValue("thread_naming_pattern", "cl")
.setValue("timer_type", "new3")
.setValue("timer_min_threads", min_cores)
.setValue("timer_max_threads", max_cores)
.setValue("timer_keep_alive_time", Util.MIN * 10)
.setValue("timer_queue_max_size", 500)
.setValue("mcast_port", Config.get("Cluster.mcast_port", Constant.INT_NULL))
.setValue("thread_pool_keep_alive_time", Util.MIN * 10)
.setValue("thread_pool_min_threads", min_cores)
.setValue("thread_pool_max_threads", max_cores)
.setValue("thread_pool_queue_enabled", false)
.setValue("thread_pool_queue_max_size", 500)
.setValue("oob_thread_pool_keep_alive_time", Util.MIN * 10)
.setValue("oob_thread_pool_min_threads", min_cores)
.setValue("oob_thread_pool_max_threads", max_cores)
.setValue("oob_thread_pool_queue_enabled", false)
.setValue("oob_thread_pool_queue_max_size", 500)
.setValue("internal_thread_pool_keep_alive_time", Util.MIN * 10)
.setValue("internal_thread_pool_min_threads", min_cores)
.setValue("internal_thread_pool_max_threads", max_cores)
.setValue("internal_thread_pool_queue_enabled", false)
.setValue("internal_thread_pool_queue_max_size", 600000)
.setValue("ucast_recv_buf_size", org.jgroups.util.Util.readBytesInteger("5M"))
.setValue("ucast_send_buf_size", org.jgroups.util.Util.readBytesInteger("640K"))
.setValue("mcast_recv_buf_size", org.jgroups.util.Util.readBytesInteger("5M"))
.setValue("mcast_send_buf_size", org.jgroups.util.Util.readBytesInteger("640K"))
)
.addProtocol(new JDBC_PING()
.setValue("connection_url", Config.get("DB.dbdriver") + ':' + Config.get("DB.dburl") + '/' + Config.get("DB.dbname"))
.setValue("connection_username", Config.get("DB.dbuser"))
.setValue("connection_password", Config.get("DB.dbpwd"))
.setValue("connection_driver", "org.postgresql.Driver")
.setValue("initialize_sql", "CREATE TABLE IF NOT EXISTS JGROUPSPING ( own_addr varchar(200) NOT NULL, cluster_name varchar(200) NOT NULL, ping_data bytea DEFAULT NULL, PRIMARY KEY (own_addr, cluster_name) )")
)
.addProtocol(new MERGE3()
.setValue("max_interval", 10000)
.setValue("min_interval", 1000)
)
.addProtocol(new FD_SOCK()
.setValue("bind_addr", bind_addr)
)
.addProtocol(new FD_ALL()
)
.addProtocol(new VERIFY_SUSPECT()
.setValue("timeout", 1000)
.setValue("bind_addr", bind_addr)
)
.addProtocol(new NAKACK2()
.setValue("xmit_interval", 500)
.setValue("xmit_table_num_rows", 100)
.setValue("xmit_table_msgs_per_row", 2000)
.setValue("xmit_table_max_compaction_time", 30000)
.setValue("max_msg_batch_size", 500)
.setValue("use_mcast_xmit", false)
.setValue("discard_delivered_msgs", true)
)
.addProtocol(new UNICAST3()
.setValue("xmit_table_num_rows", 100)
.setValue("xmit_table_msgs_per_row", 1000)
.setValue("xmit_table_max_compaction_time", 30000)
.setValue("max_msg_batch_size", 500)
)
.addProtocol(new STABLE()
.setValue("stability_delay", 2000)
.setValue("desired_avg_gossip", 60000)
.setValue("max_bytes", org.jgroups.util.Util.readBytesInteger("4M"))
.setValue("cap", 0.1)
)
.addProtocol(new GMS()
.setValue("join_timeout", 3000)
.setValue("view_bundling", false)
.setValue("print_local_addr", false)
.setValue("print_physical_addrs", false)
)
.addProtocol(new UFC()
.setValue("max_credits", org.jgroups.util.Util.readBytesInteger("4M"))
.setValue("min_threshold", 0.4)
)
.addProtocol(new MFC()
.setValue("max_credits", org.jgroups.util.Util.readBytesInteger("4M"))
.setValue("min_threshold", 0.4)
)
.addProtocol(new FRAG2()
.setValue("frag_size", org.jgroups.util.Util.readBytesInteger("60K"))
)
.addProtocol(new RSVP()
.setValue("resend_interval", 2000)
.setValue("timeout", 10000)
)
;
stack.init();
----------------------------
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4250) Manually created CDI producer methods in the Extension are not injected
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/WFLY-4250?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on WFLY-4250:
-------------------------------------------
Yes, exactly! Here is the source for [CDI module|https://github.com/infinispan/infinispan/blob/master/as-modules/em...]
> Manually created CDI producer methods in the Extension are not injected
> -----------------------------------------------------------------------
>
> Key: WFLY-4250
> URL: https://issues.jboss.org/browse/WFLY-4250
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final
> Environment: Happened on Linux environment
> Reporter: Sebastian Łaskawiec
> Assignee: Jozef Hartinger
>
> h2. Issue description:
> During migration from Wildfly 8.1 to 8.2 (Weld 2.1.2.Final -> 2.2.6.Final) in Infinispan we discovered a problem with injecting beans created programmatically in Infinispan-cdi integration module. The problem appeared in {{GreetingServiceIT}} and {{GreetingCacheManagerIT}} test. Both those tests use the following modules integrated into Wildfly:
> * org.infinispan.cdi (slot: ispn-7.1, which has dependency to "org.infinispan" slot="ispn-7.1" export="true")
> * org.infinispan.jcache (slot: ispn-7.1, which has dependency to "org.infinispan" slot="ispn-7.1" and "org.infinispan.cdi" slot="ispn-7.1" services="import")
> [Infinispan's CDI Extension|https://github.com/infinispan/infinispan/blob/master/cdi/src/ma...] invokes [{{embeddedExtension.registerCacheBeans(event, beanManager)}}|https://github.com/infinispan/infinispan/blob/master/cdi/s...], which registers custom {{Cache}} and {{AdvancedCache}} producer beans. Those beans are being successfully added to {{BeanManager}} but are never chosen for injection. All tests fail because of unsatisfied dependencies for {{Cache<CacheKey, String>}} with qualifiers {{@GreetingCache}}.
> h2. Steps to reproduce:
> * Download and unzip [https://github.com/slaskawi/infinispan/archive/upgrade_to_wf_8_2_failed_t...]
> * Run {{./build.sh clean install -pl cdi,as-modules/embedded,integrationtests/as-integration-embedded -am -DskipTests}}
> * Modify Arquillian xml if breakpoint is needed {{./integrationtests/as-integration-embedded/src/test/resources/arquillian.xml}}
> * Run test (using IDE or Maven: {{./build.sh test -pl integrationtests/as-integration-embedded -Dtest=GreetingServiceIT}})
> h2. Finding during debugging:
> At first I would suggest creating conditional breakpoints:
> * {{org.jboss.weld.bootstrap.Validator}} line 370 (WF 8.2) or 366 (WF 8.1), condition {{"[BackedAnnotatedField] @Inject @GreetingCache private org.infinispan.test.integration.as.cdi.GreetingServiceIT.greetingCache".equals(ij.toString())}} - this will stop debugger when validating injection points for {{{GreetingCache}}.
> * {{org.jboss.weld.resolution.TypeSafeResolver.ResolvableToBeanCollection}} line 51, condition {{from.toString().startsWith("Types: [org.infinispan.Cache<javax.cache.annotation.CacheKey, java.lang.String>]") || from.toString().contains("org.infinispan.Cache")}} - this stops debugger on loading {{Cache}} producer methods (created in Infinispan CDI Extension) to {{resolved}} Loading Cache in Wildfly 8.1.
> During debugging session we discovered that the beans from Infinispan's CDI Extension are created but never used for injection. This is because {{beanManager.getBeans(ij)}} in {{Validator.java}} always return empty list. In Wildfly 8.1 beans are properly resolved using {{ResolvableToBeanCollection#load}} method, but for some reason it never happens in Wildfly 8.2, because those beans are already preset in {{resolved}} Loading Cache with empty collection value. Unfortunately we couldn't find answer why.
> h2. Workaround:
> In order to fix CDI Producer Beans accessibility we need to add a new dependency to our test: {{META-INF/MANIFEST.MF: Dependencies: org.infinispan:ispn-7.1}}.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4250) Manually created CDI producer methods in the Extension are not injected
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-4250?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger commented on WFLY-4250:
---------------------------------------
Is my understanding correct that this situation happens when the deployment has dependency on org.infinispan.cdi but at the same time does not have a direct dependency on org.infinispan (this one is expected to be exported instead)?
> Manually created CDI producer methods in the Extension are not injected
> -----------------------------------------------------------------------
>
> Key: WFLY-4250
> URL: https://issues.jboss.org/browse/WFLY-4250
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final
> Environment: Happened on Linux environment
> Reporter: Sebastian Łaskawiec
> Assignee: Jozef Hartinger
>
> h2. Issue description:
> During migration from Wildfly 8.1 to 8.2 (Weld 2.1.2.Final -> 2.2.6.Final) in Infinispan we discovered a problem with injecting beans created programmatically in Infinispan-cdi integration module. The problem appeared in {{GreetingServiceIT}} and {{GreetingCacheManagerIT}} test. Both those tests use the following modules integrated into Wildfly:
> * org.infinispan.cdi (slot: ispn-7.1, which has dependency to "org.infinispan" slot="ispn-7.1" export="true")
> * org.infinispan.jcache (slot: ispn-7.1, which has dependency to "org.infinispan" slot="ispn-7.1" and "org.infinispan.cdi" slot="ispn-7.1" services="import")
> [Infinispan's CDI Extension|https://github.com/infinispan/infinispan/blob/master/cdi/src/ma...] invokes [{{embeddedExtension.registerCacheBeans(event, beanManager)}}|https://github.com/infinispan/infinispan/blob/master/cdi/s...], which registers custom {{Cache}} and {{AdvancedCache}} producer beans. Those beans are being successfully added to {{BeanManager}} but are never chosen for injection. All tests fail because of unsatisfied dependencies for {{Cache<CacheKey, String>}} with qualifiers {{@GreetingCache}}.
> h2. Steps to reproduce:
> * Download and unzip [https://github.com/slaskawi/infinispan/archive/upgrade_to_wf_8_2_failed_t...]
> * Run {{./build.sh clean install -pl cdi,as-modules/embedded,integrationtests/as-integration-embedded -am -DskipTests}}
> * Modify Arquillian xml if breakpoint is needed {{./integrationtests/as-integration-embedded/src/test/resources/arquillian.xml}}
> * Run test (using IDE or Maven: {{./build.sh test -pl integrationtests/as-integration-embedded -Dtest=GreetingServiceIT}})
> h2. Finding during debugging:
> At first I would suggest creating conditional breakpoints:
> * {{org.jboss.weld.bootstrap.Validator}} line 370 (WF 8.2) or 366 (WF 8.1), condition {{"[BackedAnnotatedField] @Inject @GreetingCache private org.infinispan.test.integration.as.cdi.GreetingServiceIT.greetingCache".equals(ij.toString())}} - this will stop debugger when validating injection points for {{{GreetingCache}}.
> * {{org.jboss.weld.resolution.TypeSafeResolver.ResolvableToBeanCollection}} line 51, condition {{from.toString().startsWith("Types: [org.infinispan.Cache<javax.cache.annotation.CacheKey, java.lang.String>]") || from.toString().contains("org.infinispan.Cache")}} - this stops debugger on loading {{Cache}} producer methods (created in Infinispan CDI Extension) to {{resolved}} Loading Cache in Wildfly 8.1.
> During debugging session we discovered that the beans from Infinispan's CDI Extension are created but never used for injection. This is because {{beanManager.getBeans(ij)}} in {{Validator.java}} always return empty list. In Wildfly 8.1 beans are properly resolved using {{ResolvableToBeanCollection#load}} method, but for some reason it never happens in Wildfly 8.2, because those beans are already preset in {{resolved}} Loading Cache with empty collection value. Unfortunately we couldn't find answer why.
> h2. Workaround:
> In order to fix CDI Producer Beans accessibility we need to add a new dependency to our test: {{META-INF/MANIFEST.MF: Dependencies: org.infinispan:ispn-7.1}}.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-2518) arquillian - domain container - exception when connecting to existing domain without any servers
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2518?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2518:
-----------------------------------------------
Martin Simka <msimka(a)redhat.com> changed the Status of [bug 1175268|https://bugzilla.redhat.com/show_bug.cgi?id=1175268] from ON_QA to VERIFIED
> arquillian - domain container - exception when connecting to existing domain without any servers
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-2518
> URL: https://issues.jboss.org/browse/WFLY-2518
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Martin Simka
> Assignee: Martin Simka
> Priority: Minor
> Fix For: 8.0.0.CR1
>
>
> {noformat}
> (E) ManagerProcessing
> (O) LoadableExtensionLoader.load
> (E) ServiceLoader
> (E) ManagerStarted
> (O) ConfigurationRegistrar.loadConfiguration
> (E) ArquillianDescriptor
> (O) ContainerRegistryCreator.createRegistry
> (E) ContainerRegistry
> (O) ProtocolRegistryCreator.createRegistry
> (E) ProtocolRegistry
> (E) BeforeSuite
> (I) TestContextHandler.createSuiteContext
> (O) ContainerEventController.execute
> (E) ContainerMultiControlEvent
> (O) ContainerLifecycleController.setupContainers
> (E) SetupContainer
> (I) ContainerDeploymentContextHandler.createContainerContext
> (O) ContainerLifecycleController.setupContainer
> (E) BeforeSetup
> (E) Container
> (E) AfterSetup
> (O) ClientContainerControllerCreator.createClientSideContainerController
> (E) ContainerController
> (O) ClientDeployerCreator.createClientSideDeployer
> (E) Deployer
> (E) ContainerMultiControlEvent
> (O) ContainerLifecycleController.startSuiteContainers
> (E) StartContainer
> (I) ContainerDeploymentContextHandler.createContainerContext
> (O) ContainerLifecycleController.startContainer
> (E) BeforeStart
> (E) ManagementClient
> (E) ArchiveDeployer
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> java.lang.IllegalArgumentException: null
> at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:124)
> at org.jboss.dmr.ModelNode.keys(ModelNode.java:1194)
> at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:116)
> at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:126)
> at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-3900) Unable to inject EJB Context into CDI Interceptor
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3900?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3900:
-----------------------------------------------
Matous Jobanek <mjobanek(a)redhat.com> changed the Status of [bug 1149646|https://bugzilla.redhat.com/show_bug.cgi?id=1149646] from ON_QA to VERIFIED
> Unable to inject EJB Context into CDI Interceptor
> -------------------------------------------------
>
> Key: WFLY-3900
> URL: https://issues.jboss.org/browse/WFLY-3900
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 9.0.0.Alpha1
> Reporter: Brad Maxwell
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
> Attachments: inject-ejb-context-into-cdi-interceptor.jar, server.log
>
>
> CDI Interceptor cannot inject EJB session context.
> If the Interceptor is changed to EJB interceptor by removing the @Interceptor on the interceptor and removing it from the beans.xml, and adding @Interceptors(...) to the EJB, then it is able to inject.
> See attached reproducer with source and log file.
> private @Resource SessionContext sessionContext;
> Caused by: javax.naming.NameNotFoundException: env/test.ServiceLoggedInterceptor/sessionContext -- service jboss.naming.context.java.comp.inject-ejb-context-into-cdi-interceptor.inject-ejb-context-into-cdi-interceptor.HelloEJB.env."test.ServiceLoggedInterceptor".sessionContext
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51]
> at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:185)
> ... 127 more
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-3578) jboss-cli.bat always exits with return code 0 even after a cli failure
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-3578?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky commented on WFLY-3578:
-----------------------------------------
That's correct. Thanks for noticing. The fix was merged into the split from the WildFly wildfly-core project and made it into WildFly-9.0.0.Alpha1 eventually.
> jboss-cli.bat always exits with return code 0 even after a cli failure
> ----------------------------------------------------------------------
>
> Key: WFLY-3578
> URL: https://issues.jboss.org/browse/WFLY-3578
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 8.1.0.Final
> Environment: Windows
> Reporter: Gabriele Garuglieri
> Assignee: Alexey Loubyansky
> Fix For: 9.0.0.Alpha1
>
>
> jboss-cli.bat cannot be reliably controlled by other scripts because it does not report return code from cli execution and always exits with 0 even after a failure.
> It can be solved with the following patch:
> {noformat}
> --- C:/home/JBoss/wildfly-8.1.0.Final/bin/jboss-cli-orig.bat Sat May 31 04:54:25 2014
> +++ C:/home/JBoss/wildfly-8.1.0.Final/bin/jboss-cli.bat Thu Jul 03 10:19:09 2014
> @@ -1,4 +1,5 @@
> @echo off
> +setlocal ENABLEEXTENSIONS
> rem -------------------------------------------------------------------------
> rem JBoss Admin CLI Script for Windows
> rem -------------------------------------------------------------------------
> @@ -48,6 +49,7 @@
> if not exist "%JBOSS_RUNJAR%" (
> echo Could not locate "%JBOSS_RUNJAR%".
> echo Please check that you are in the bin directory when running this script.
> + set /A RC=1
> goto END
> )
>
> @@ -71,5 +73,11 @@
> org.jboss.as.cli ^
> %*
>
> +set /A RC=%errorlevel%
> :END
> if "x%NOPAUSE%" == "x" pause
> +
> +if "x%RC%" == "x" (
> + set /A RC=0
> +)
> +exit /B %RC%
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4250) Manually created CDI producer methods in the Extension are not injected
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/WFLY-4250?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on WFLY-4250:
-------------------------------------------
We are injecting into: {{[BackedAnnotatedField] @Inject @GreetingCache private org.infinispan.test.integration.as.cdi.GreetingCacheManager.cache}}. The field has type: {{org.infinispan.Cache}}
The bean, which is not injected is a producer of type {{interface org.infinispan.AdvancedCache}}. It extends {{org.infinispan.Cache}}.
When I stop the debugger at {{org.jboss.weld.bootstrap.Validator#validateInjectionPointForDeploymentProblems}} and look for the bean, which should be injected I find this:
* There are 13 Bean Managers in total:
** {{Weld BeanManager for org.hibernate.validator:main.additionalClasses [bean count=4]}}
** {{Weld BeanManager for org.jberet.jberet-core:main.additionalClasses [bean count=89]}}
** {{Weld BeanManager for cdi.war/WEB-INF/classes [bean count=37]}}
** {{Weld BeanManager for com.sun.jsf-impl:main.additionalClasses [bean count=36]}}
** {{Weld BeanManager for deployment.cdi.war:main.additionalClasses [bean count=30]}}
** {{Weld BeanManager for cdi.war.external.jar:file:/home/slaskawiec/work/infinispan/infinispan/integrationtests/as-integration-embedded/target/node1/wildfly-8.2.0.Final/modules/org/infinispan/jcache/ispn-7.1/infinispan-jcache.jar!/META-INF/beans.xml [bean count=46]}}
** {{Weld BeanManager for org.jboss.resteasy.resteasy-cdi:main.additionalClasses [bean count=30]}}
** {{Weld BeanManager for /content/cdi.war/WEB-INF/lib/arquillian-protocol.jar [bean count=30]}}
** {{Weld BeanManager for deployment [bean count=14]}}
** {{Weld BeanManager for org.jboss.as.jsf:main.additionalClasses [bean count=30]}}
** {{Weld BeanManager for org.hibernate.validator.cdi:main.additionalClasses [bean count=30]}}
** {{Weld BeanManager for cdi.war.external.jar:file:/home/slaskawiec/work/infinispan/infinispan/integrationtests/as-integration-embedded/target/node1/wildfly-8.2.0.Final/}}modules/org/infinispan/cdi/ispn-7.1/infinispan-cdi.jar!/META-INF/beans.xml [bean count=102]}}
** {{Weld BeanManager for org.infinispan:ispn-7.1.additionalClasses [bean count=5]}}
* The last one contains the bean we are looking for:
** {{Custom Bean with bean class interface org.infinispan.AdvancedCache and qualifiers [@javax.enterprise.inject.Any(), @org.infinispan.test.integration.as.cdi.GreetingCache()]}}
** Bean class: {{interface org.infinispan.AdvancedCache}}.
* beanManager parameter is bound to {{Weld BeanManager for cdi.war/WEB-INF/classes [bean count=37]}}
> Manually created CDI producer methods in the Extension are not injected
> -----------------------------------------------------------------------
>
> Key: WFLY-4250
> URL: https://issues.jboss.org/browse/WFLY-4250
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final
> Environment: Happened on Linux environment
> Reporter: Sebastian Łaskawiec
> Assignee: Jozef Hartinger
>
> h2. Issue description:
> During migration from Wildfly 8.1 to 8.2 (Weld 2.1.2.Final -> 2.2.6.Final) in Infinispan we discovered a problem with injecting beans created programmatically in Infinispan-cdi integration module. The problem appeared in {{GreetingServiceIT}} and {{GreetingCacheManagerIT}} test. Both those tests use the following modules integrated into Wildfly:
> * org.infinispan.cdi (slot: ispn-7.1, which has dependency to "org.infinispan" slot="ispn-7.1" export="true")
> * org.infinispan.jcache (slot: ispn-7.1, which has dependency to "org.infinispan" slot="ispn-7.1" and "org.infinispan.cdi" slot="ispn-7.1" services="import")
> [Infinispan's CDI Extension|https://github.com/infinispan/infinispan/blob/master/cdi/src/ma...] invokes [{{embeddedExtension.registerCacheBeans(event, beanManager)}}|https://github.com/infinispan/infinispan/blob/master/cdi/s...], which registers custom {{Cache}} and {{AdvancedCache}} producer beans. Those beans are being successfully added to {{BeanManager}} but are never chosen for injection. All tests fail because of unsatisfied dependencies for {{Cache<CacheKey, String>}} with qualifiers {{@GreetingCache}}.
> h2. Steps to reproduce:
> * Download and unzip [https://github.com/slaskawi/infinispan/archive/upgrade_to_wf_8_2_failed_t...]
> * Run {{./build.sh clean install -pl cdi,as-modules/embedded,integrationtests/as-integration-embedded -am -DskipTests}}
> * Modify Arquillian xml if breakpoint is needed {{./integrationtests/as-integration-embedded/src/test/resources/arquillian.xml}}
> * Run test (using IDE or Maven: {{./build.sh test -pl integrationtests/as-integration-embedded -Dtest=GreetingServiceIT}})
> h2. Finding during debugging:
> At first I would suggest creating conditional breakpoints:
> * {{org.jboss.weld.bootstrap.Validator}} line 370 (WF 8.2) or 366 (WF 8.1), condition {{"[BackedAnnotatedField] @Inject @GreetingCache private org.infinispan.test.integration.as.cdi.GreetingServiceIT.greetingCache".equals(ij.toString())}} - this will stop debugger when validating injection points for {{{GreetingCache}}.
> * {{org.jboss.weld.resolution.TypeSafeResolver.ResolvableToBeanCollection}} line 51, condition {{from.toString().startsWith("Types: [org.infinispan.Cache<javax.cache.annotation.CacheKey, java.lang.String>]") || from.toString().contains("org.infinispan.Cache")}} - this stops debugger on loading {{Cache}} producer methods (created in Infinispan CDI Extension) to {{resolved}} Loading Cache in Wildfly 8.1.
> During debugging session we discovered that the beans from Infinispan's CDI Extension are created but never used for injection. This is because {{beanManager.getBeans(ij)}} in {{Validator.java}} always return empty list. In Wildfly 8.1 beans are properly resolved using {{ResolvableToBeanCollection#load}} method, but for some reason it never happens in Wildfly 8.2, because those beans are already preset in {{resolved}} Loading Cache with empty collection value. Unfortunately we couldn't find answer why.
> h2. Workaround:
> In order to fix CDI Producer Beans accessibility we need to add a new dependency to our test: {{META-INF/MANIFEST.MF: Dependencies: org.infinispan:ispn-7.1}}.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-3578) jboss-cli.bat always exits with return code 0 even after a cli failure
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-3578?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky updated WFLY-3578:
------------------------------------
Fix Version/s: 9.0.0.Alpha1
(was: 8.2.0.Final)
> jboss-cli.bat always exits with return code 0 even after a cli failure
> ----------------------------------------------------------------------
>
> Key: WFLY-3578
> URL: https://issues.jboss.org/browse/WFLY-3578
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 8.1.0.Final
> Environment: Windows
> Reporter: Gabriele Garuglieri
> Assignee: Alexey Loubyansky
> Fix For: 9.0.0.Alpha1
>
>
> jboss-cli.bat cannot be reliably controlled by other scripts because it does not report return code from cli execution and always exits with 0 even after a failure.
> It can be solved with the following patch:
> {noformat}
> --- C:/home/JBoss/wildfly-8.1.0.Final/bin/jboss-cli-orig.bat Sat May 31 04:54:25 2014
> +++ C:/home/JBoss/wildfly-8.1.0.Final/bin/jboss-cli.bat Thu Jul 03 10:19:09 2014
> @@ -1,4 +1,5 @@
> @echo off
> +setlocal ENABLEEXTENSIONS
> rem -------------------------------------------------------------------------
> rem JBoss Admin CLI Script for Windows
> rem -------------------------------------------------------------------------
> @@ -48,6 +49,7 @@
> if not exist "%JBOSS_RUNJAR%" (
> echo Could not locate "%JBOSS_RUNJAR%".
> echo Please check that you are in the bin directory when running this script.
> + set /A RC=1
> goto END
> )
>
> @@ -71,5 +73,11 @@
> org.jboss.as.cli ^
> %*
>
> +set /A RC=%errorlevel%
> :END
> if "x%NOPAUSE%" == "x" pause
> +
> +if "x%RC%" == "x" (
> + set /A RC=0
> +)
> +exit /B %RC%
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months