[JBoss JIRA] (DROOLS-972) CDI annotations are not following CDI scopes
by Mauricio Salatino (JIRA)
Mauricio Salatino created DROOLS-972:
----------------------------------------
Summary: CDI annotations are not following CDI scopes
Key: DROOLS-972
URL: https://issues.jboss.org/browse/DROOLS-972
Project: Drools
Issue Type: Feature Request
Reporter: Mauricio Salatino
Assignee: Mario Fusco
I'm wondering if it is just a missing feature of if there is a technical limitation why we are not following the CDI scopes approach.
To be concrete what I wanted to achieve is to have
Something like this:
@Inject
@KReleaseId(groupId = "xxx", artifactId = "xxxxx", version = "1.0-SNAPSHOT")
@KSession
private KieSession kSession;
Inside a bean with @ApplicationScoped.. that works well because the KieSession is application scoped and shared between different requests, but now when I do
@RequestScoped or @SessionScoped the KieSession is still shared :(
I imagine that supporting these two scopes should be fairly easy from the CDI point of view:
1) @RequestScoped: just recreate the session everytime and look for the @ReleaseId everytime, because the idea is that if the ReleaseId is updated, the new request will need to load the new ReleaseId artifact
2) @BusinessSessionScoped: the session will have an ID and just a check is needed, if the session exist just use the KieSession registered for that ID, if it doesn't exist create a new one. Notice that I didn't use the existing @SessionScoped because that is usually tied to the HTTPSession, which might be another case.
The lack of scopes also interfere with Arquillian for CDI testing, the @Ksession annotation seems to be creating a singleton, so when JUnit fork to execute several tests in parallel the @Injected @Ksession is shared among all the tests :(
I'm sure that you guys already know about this, but I just wrote it down to state clear what the user expectations are regarding this and also to clarify my thoughts. If you guys can guide me and give me some pointers I can even help on this side.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5640) No EJB receiver available for handling
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5640?page=com.atlassian.jira.plugin.... ]
Paul Ferraro reassigned WFLY-5640:
----------------------------------
Assignee: Richard Achmatowicz (was: Paul Ferraro)
> No EJB receiver available for handling
> --------------------------------------
>
> Key: WFLY-5640
> URL: https://issues.jboss.org/browse/WFLY-5640
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB, Test Suite
> Affects Versions: 10.0.0.CR4
> Environment: hp-ux 11v3 - hpjdk1.8
> solaris 10,11 - x86 and x86_64, rhel 6 - x86 and x86_64, rhel 7 x86_64 - openjdk1.8, ibmjdk1.8, oraclejdk1.8
> Reporter: Ivan Straka
> Assignee: Richard Achmatowicz
> Attachments: logs
>
>
> There are two tests failing in exteded tests in clusteringejb2 package in AS TS.
> org.jboss.as.test.clustering.extended.ejb2.stateless.RemoteStatelessFailoverTestCase(SYNC-tcp-extended)#testLoadbalanceSpecifiedByDescriptor
> org.jboss.as.test.clustering.extended.ejb2.stateless.RemoteStatelessFailoverTestCase(SYNC-tcp-extended)#testLoadbalanceAnnotatedBean
> both with exception
> {code}
> Error Message
> EJBCLIENT000025: No EJB receiver available for handling [appName:, moduleName:stateless-ejb2-failover-test, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@54acff7d
> Stacktrace
> java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:, moduleName:stateless-ejb2-failover-test, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@54acff7d
> at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:798)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:112)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy28.create(Unknown Source)
> at org.jboss.as.test.clustering.extended.ejb2.stateless.RemoteStatelessFailoverTestCase.loadbalance(RemoteStatelessFailoverTestCase.java:262)
> at org.jboss.as.test.clustering.extended.ejb2.stateless.RemoteStatelessFailoverTestCase.testLoadbalanceAnnotatedBean(RemoteStatelessFailoverTestCase.java:224)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-3211) java:app resources can not be shared between ejb and appclient modules
by Wolfgang Knauf (JIRA)
[ https://issues.jboss.org/browse/WFLY-3211?page=com.atlassian.jira.plugin.... ]
Wolfgang Knauf commented on WFLY-3211:
--------------------------------------
It seems I cannot modify the issue data. Could someone with more privileges add WF 10 in the "Affects versions" field?
> java:app resources can not be shared between ejb and appclient modules
> ----------------------------------------------------------------------
>
> Key: WFLY-3211
> URL: https://issues.jboss.org/browse/WFLY-3211
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 8.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Eduardo Martins
> Attachments: Sample_WildFly10.zip
>
>
> use case:
> 1 ear composed of:
> 1 appclient module that defines 2 JMS queues (one in java:app, the other in java:global)
> 1 ejb modules with 2 MDBs (one listening to the java:app queue and the other to the java:global queue)
> When the ear is deployed:
> 1. the ejb module is deployed, the MDBs are created and wait for the creations of their respective queues (defined in the appclient module)
> 2. the appclient module is deployed, its 2 queues are deployed
> 3. the appclient main is run
> When the appclient uses the java:global queue, it looks it up, sends the message and the corresponding MDB receives it fine.
> When the appclient uses the java:app queue, it looks it up, sends the message but the corresponding MDB never receives it
> => the MDB was never deployed because it did not see the java:app queue deployed from the appclient module.
> Note that if I move the destination definitions to the ejb module, the MDBs are correctly activated but the appclient module is no longer deployed with errors:
> {noformat}
> [APPCLIENT-out] {"JBAS014771: Services with missing/unavailable dependencies" => [
> [APPCLIENT-out] "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInGlobal is missing [jboss.naming.context.java.global.jms.queu
> e.queue1]",
> [APPCLIENT-out] "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInApp is missing [jboss.naming.context.java.app.simple-jms-app
> client-test.jms.queue.queue2]"
> [APPCLIENT-out] ]}
> {noformat}
> Steps to reproduce:
> 1. fetch git branch https://github.com/jmesnil/wildfly/tree/jms_appclient
> 2. build WildFly
> 3. run ./integration-tests.sh -Dts.basic -Dtest=org.jboss.as.test.integration.ee.appclient.jms.basic.SimpleJMSApplicationClientTestCase -DnoWebProfile
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-3211) java:app resources can not be shared between ejb and appclient modules
by Wolfgang Knauf (JIRA)
[ https://issues.jboss.org/browse/WFLY-3211?page=com.atlassian.jira.plugin.... ]
Wolfgang Knauf commented on WFLY-3211:
--------------------------------------
The same problem happens on WildFly 10.0.0CR4.
Attached is my sample app which was be base for the initial issue (see also https://developer.jboss.org/message/863696). The zip file contains an EAR file and a modified "appclient.xml" for WF10 which defines the jms related stuff.
To reproduce:
-deploy "Message.ear" to WF 10
-copy client config to %WILDFLY_HOME%\appclient\configuration"
-start client: %WILDFLY_HOME%\bin\appclient.bat c:\Path\To\Message.ear#MessageClient.jar
Error message:
2015-11-07 20:17:24,220 ERROR [org.jboss.as.controller.management-operation] (Thread-40) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "Message.ear")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.Message.MessageClient.env.jms.MBQueueRef is missing [jboss.naming.context.java.app.Message.jms.queue.MessageBeanQueue]"]}
2015-11-07 20:17:24,223 ERROR [org.jboss.as.server] (Thread-40) WFLYSRV0021: Deploy of deployment "Message.ear" was rolled back with the following failure message: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.Message.MessageClient.env.jms.MBQueueRef is missing [jboss.naming.context.java.app.Message.jms.queue.MessageBeanQueue]"]}
> java:app resources can not be shared between ejb and appclient modules
> ----------------------------------------------------------------------
>
> Key: WFLY-3211
> URL: https://issues.jboss.org/browse/WFLY-3211
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 8.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Eduardo Martins
> Attachments: Sample_WildFly10.zip
>
>
> use case:
> 1 ear composed of:
> 1 appclient module that defines 2 JMS queues (one in java:app, the other in java:global)
> 1 ejb modules with 2 MDBs (one listening to the java:app queue and the other to the java:global queue)
> When the ear is deployed:
> 1. the ejb module is deployed, the MDBs are created and wait for the creations of their respective queues (defined in the appclient module)
> 2. the appclient module is deployed, its 2 queues are deployed
> 3. the appclient main is run
> When the appclient uses the java:global queue, it looks it up, sends the message and the corresponding MDB receives it fine.
> When the appclient uses the java:app queue, it looks it up, sends the message but the corresponding MDB never receives it
> => the MDB was never deployed because it did not see the java:app queue deployed from the appclient module.
> Note that if I move the destination definitions to the ejb module, the MDBs are correctly activated but the appclient module is no longer deployed with errors:
> {noformat}
> [APPCLIENT-out] {"JBAS014771: Services with missing/unavailable dependencies" => [
> [APPCLIENT-out] "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInGlobal is missing [jboss.naming.context.java.global.jms.queu
> e.queue1]",
> [APPCLIENT-out] "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInApp is missing [jboss.naming.context.java.app.simple-jms-app
> client-test.jms.queue.queue2]"
> [APPCLIENT-out] ]}
> {noformat}
> Steps to reproduce:
> 1. fetch git branch https://github.com/jmesnil/wildfly/tree/jms_appclient
> 2. build WildFly
> 3. run ./integration-tests.sh -Dts.basic -Dtest=org.jboss.as.test.integration.ee.appclient.jms.basic.SimpleJMSApplicationClientTestCase -DnoWebProfile
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-3211) java:app resources can not be shared between ejb and appclient modules
by Wolfgang Knauf (JIRA)
[ https://issues.jboss.org/browse/WFLY-3211?page=com.atlassian.jira.plugin.... ]
Wolfgang Knauf updated WFLY-3211:
---------------------------------
Attachment: Sample_WildFly10.zip
> java:app resources can not be shared between ejb and appclient modules
> ----------------------------------------------------------------------
>
> Key: WFLY-3211
> URL: https://issues.jboss.org/browse/WFLY-3211
> Project: WildFly
> Issue Type: Bug
> Components: Naming
> Affects Versions: 8.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Eduardo Martins
> Attachments: Sample_WildFly10.zip
>
>
> use case:
> 1 ear composed of:
> 1 appclient module that defines 2 JMS queues (one in java:app, the other in java:global)
> 1 ejb modules with 2 MDBs (one listening to the java:app queue and the other to the java:global queue)
> When the ear is deployed:
> 1. the ejb module is deployed, the MDBs are created and wait for the creations of their respective queues (defined in the appclient module)
> 2. the appclient module is deployed, its 2 queues are deployed
> 3. the appclient main is run
> When the appclient uses the java:global queue, it looks it up, sends the message and the corresponding MDB receives it fine.
> When the appclient uses the java:app queue, it looks it up, sends the message but the corresponding MDB never receives it
> => the MDB was never deployed because it did not see the java:app queue deployed from the appclient module.
> Note that if I move the destination definitions to the ejb module, the MDBs are correctly activated but the appclient module is no longer deployed with errors:
> {noformat}
> [APPCLIENT-out] {"JBAS014771: Services with missing/unavailable dependencies" => [
> [APPCLIENT-out] "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInGlobal is missing [jboss.naming.context.java.global.jms.queu
> e.queue1]",
> [APPCLIENT-out] "jboss.naming.context.java.module.simple-jms-appclient-test.appclient.env.jms.queueInApp is missing [jboss.naming.context.java.app.simple-jms-app
> client-test.jms.queue.queue2]"
> [APPCLIENT-out] ]}
> {noformat}
> Steps to reproduce:
> 1. fetch git branch https://github.com/jmesnil/wildfly/tree/jms_appclient
> 2. build WildFly
> 3. run ./integration-tests.sh -Dts.basic -Dtest=org.jboss.as.test.integration.ee.appclient.jms.basic.SimpleJMSApplicationClientTestCase -DnoWebProfile
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4562) Deprecate Infinispan container/cache start mode
by xiaodong xie (JIRA)
[ https://issues.jboss.org/browse/WFLY-4562?page=com.atlassian.jira.plugin.... ]
xiaodong xie commented on WFLY-4562:
------------------------------------
Sure, @Paul. I'm working on creating a test case that could reproduce this issue.
But it seems I cannot reproduce it right now. The thing that I noticed, is that, when I failed to inject with @Resource, there is no log output "ISPN000128: Infinispan version: Infinispan 'Insanely Bad Elf' 7.2.3.Final". So I suspect, the Infinispan module was not ready, when the application tried to get a cache injected.
I'll continue to dig deeper, to see if I could find anything else...
> Deprecate Infinispan container/cache start mode
> -----------------------------------------------
>
> Key: WFLY-4562
> URL: https://issues.jboss.org/browse/WFLY-4562
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 9.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 9.0.0.CR1
>
>
> start="EAGER" was only added to the Infinispan subsystem for use by JDG - so that a given container or cache service would install as ACTIVE rather than ON_DEMAND. In the context of WildFly, we would never want this since the modules referenced by cache entries may not yet be loaded. Many users configure start="EAGER" and inevitably have issues during redeploy. Consequently, we should drop this from the subsystem XSD altogether and deprecate it from the model.
> Effectively, only start="LAZY" will be supported.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4338) JConsole script builds wrong path
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4338?page=com.atlassian.jira.plugin.... ]
Kabir Khan reassigned WFLY-4338:
--------------------------------
Assignee: (was: Kabir Khan)
> JConsole script builds wrong path
> ---------------------------------
>
> Key: WFLY-4338
> URL: https://issues.jboss.org/browse/WFLY-4338
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Affects Versions: 8.2.0.Final
> Environment: Linux (Ubuntu 14.10) and Mac OS X Yosemite (10.10.2)
> Reporter: André Lemos
> Priority: Trivial
> Labels: bash, jconsole, wildfly
> Attachments: jconsole.patch
>
>
> The path built by the jconsole.sh script is incorrect, and as a result, when calling {{service:jmx:http-remoting-jmx://{insert server ip here}:9990}} is probably never recognized and the connection is never done.
> The path, under mac is:
> {{/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/bin/jconsole -J-Djava.class.path=/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/lib/jconsole.jar:/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/lib/tools.jar:"/Users/user/Documents/playground/wild/wildfly-8.2.0.Final"/bin/client/jboss-cli-client.jar}}
> So, there are " on the path for the jboss-cli-client.jar. which breaks things. This problem happens with both Linux and Mac.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4562) Deprecate Infinispan container/cache start mode
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-4562?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-4562:
------------------------------------
[~sflanigan] To answer your original question - use a <resource-ref/> or <resource-env-ref/>. This serves 2 purposes:
# Allows you to lookup the resource from a standard namespace (e.g. java:comp/env).
# Ensures the component lifecycle is bound to your bean.
[~xxd] @Resource injection _should_ ensure that the resource is started - although I have seen reports that this isn't happening for CDI beans. Can you file jira for this?
> Deprecate Infinispan container/cache start mode
> -----------------------------------------------
>
> Key: WFLY-4562
> URL: https://issues.jboss.org/browse/WFLY-4562
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 9.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 9.0.0.CR1
>
>
> start="EAGER" was only added to the Infinispan subsystem for use by JDG - so that a given container or cache service would install as ACTIVE rather than ON_DEMAND. In the context of WildFly, we would never want this since the modules referenced by cache entries may not yet be loaded. Many users configure start="EAGER" and inevitably have issues during redeploy. Consequently, we should drop this from the subsystem XSD altogether and deprecate it from the model.
> Effectively, only start="LAZY" will be supported.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5639) ARQ managed domain fails with assertions enabled
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-5639?page=com.atlassian.jira.plugin.... ]
James Perkins closed WFLY-5639.
-------------------------------
Resolution: Duplicate Issue
I'm closing this a duplicate because it was fixed in https://issues.jboss.org/browse/WFCORE-988.
> ARQ managed domain fails with assertions enabled
> ------------------------------------------------
>
> Key: WFLY-5639
> URL: https://issues.jboss.org/browse/WFLY-5639
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Thomas Diesler
>
> Currently we have
> {code:xml}
> <container qualifier="jboss" default="true">
> <configuration>
> <property name="jbossHome">${jboss.home}</property>
> <property name="allowConnectingToRunningServer">true</property>
> <property name="enableAssertions">false</property>
> </configuration>
> </container>
> {code}
> With assertions enabled (the default)
> {code}
> Caused by: org.jboss.as.controller.client.helpers.domain.UpdateFailedException: "WFLYDC0022: Operation failed or was rolled back on all servers."
> at org.jboss.as.controller.client.helpers.domain.impl.DomainDeploymentPlanResultFuture.createFailureResults(DomainDeploymentPlanResultFuture.java:133)
> at org.jboss.as.controller.client.helpers.domain.impl.DomainDeploymentPlanResultFuture.getResultFromNode(DomainDeploymentPlanResultFuture.java:105)
> at org.jboss.as.controller.client.helpers.domain.impl.DomainDeploymentPlanResultFuture.get(DomainDeploymentPlanResultFuture.java:87)
> at org.jboss.as.controller.client.helpers.domain.impl.DomainDeploymentPlanResultFuture.get(DomainDeploymentPlanResultFuture.java:49)
> at org.jboss.as.arquillian.container.domain.ArchiveDeployer.executeDeploymentPlan(ArchiveDeployer.java:90)
> at org.jboss.as.arquillian.container.domain.ArchiveDeployer.deploy(ArchiveDeployer.java:62)
> at org.jboss.as.arquillian.container.domain.ServerGroupContainer.deploy(ServerGroupContainer.java:103)
> {code}
> The test.war deployment is added to the rempository, deployment then fails for some unknown reason
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-851) Remoting Subsystem RemoteOutboundConnectionService is caching ConnectionURI causing issues when DNS changes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-851?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-851:
------------------------------------------------
Panagiotis Sotiropoulos <psotirop(a)redhat.com> changed the Status of [bug 1248156|https://bugzilla.redhat.com/show_bug.cgi?id=1248156] from NEW to ASSIGNED
> Remoting Subsystem RemoteOutboundConnectionService is caching ConnectionURI causing issues when DNS changes
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-851
> URL: https://issues.jboss.org/browse/WFCORE-851
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Reporter: Brad Maxwell
> Assignee: David Lloyd
>
> Description of problem:
> EJB CLient was configured with DNS FQDN to configure access to a remote EJB. If run a simple test adding an entry in /etc/hosts file pointing that FQDN to localhost for tests everything works. However, after finish the tests and remove the entry, the client still connects to localhost instead of resolve the new IP address. Even adding networkaddress.cache.ttl=30 inside security settings didn't work too.
> How reproducible:
> Everytime you use DNS names to connect to a remote EJB.
> Steps to Reproduce:
> 1. Configure a simple client that connects to a remote EJB using dns name
> 2. add an entry in /etc/hosts mapping the dns name to localhost
> 3. run the client code
> 4. remove the entry in /etc/hosts
> 5. run the client code again
> Actual results:
> EJB remote is still reached from localhost
> Expected results:
> After changing DNS record EJB will be reached in this new address
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months