[JBoss JIRA] (WFLY-3386) Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-3386?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger reassigned WFLY-3386:
-------------------------------------
Assignee: Martin Kouba (was: Jozef Hartinger)
> Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-3386
> URL: https://issues.jboss.org/browse/WFLY-3386
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.Final
> Environment: CentOS, Mac (Mountain Lion).
> Reporter: Andries Ehlers
> Assignee: Martin Kouba
>
> Background:
> The actual exception seems to be very close the one in issue: WFLY-3001 but we are not using JSF at all, but Activiti CDI.
> Not sure if this is a Wildfly or Activiti issue - it could very well be that there is a bug in Activiti with how it manages the CDI scopes. Unfortunately we're at a loss and seeing that the nullpointer is thrown from within a weld AbstractSessionBeanStore, I decided to post it here. Please advise.
> Error:
> We use Activiti CDI within Wildfly 8.0.0.Final. We randomly encounter an issue (sometimes immediately after a redeploy, other times after a few hours of inactivity on the server) the following issue. When Activiti attempts to retrieve the ContextBeanInstance from its ConversationScopedAssociationProxy, a NullPointer exception is thrown while attempting to retrieve the lock store within Weld (see below).
> -----------------------------
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) java.lang.NullPointerException: null
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:90) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager$ConversationScopedAssociation$Proxy$_$$_WeldClientProxy.getTask(Unknown Source) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager.getTask(DefaultContextAssociationManager.java:237) ~[activiti-cdi-5.15.jar:na]
> 2014-05-21 10:05:34,432 INFO [stdout] (default task-12) at org.activiti.cdi.BusinessProcess.startTask(BusinessProcess.java:332) ~[activiti-cdi-5.15.jar:na]
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (WFLY-3329) EJBs with same Java class name not intercepted by CDI interceptors
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-3329?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger reassigned WFLY-3329:
-------------------------------------
Assignee: Martin Kouba (was: Stuart Douglas)
> EJBs with same Java class name not intercepted by CDI interceptors
> ------------------------------------------------------------------
>
> Key: WFLY-3329
> URL: https://issues.jboss.org/browse/WFLY-3329
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: JBoss AS7 7.1.1.Final, JBoss AS7 7.2.0.Final, 8.0.0.Final
> Reporter: Maxim Frolov
> Assignee: Martin Kouba
> Labels: ejb, ejb3.1, interceptor
>
> h3. Given
> Two or more EJBs with the same Java class name but from different Java deployments.
> h3. Problem
> Interceptor intercepts method calls to only one of the EJBs.
> An EJB to be intercepted seems to be chosen randomly after each redeployment.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (WFLY-2789) Remote client transaction timeout values are overwrote by hardcoded values
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2789?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2789:
-----------------------------------------------
Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1093752|https://bugzilla.redhat.com/show_bug.cgi?id=1093752] from POST to MODIFIED
> Remote client transaction timeout values are overwrote by hardcoded values
> --------------------------------------------------------------------------
>
> Key: WFLY-2789
> URL: https://issues.jboss.org/browse/WFLY-2789
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Johnathon Lee
> Assignee: David Lloyd
> Fix For: 8.1.0.Final, 9.0.0.Alpha1
>
>
> The EJB3 interceptor is not using client values for timeouts, this is a problem for users trying to use EJB for transaction propagation.
> Refer to the code in https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...:
> private void createOrResumeXidTransaction(final XidTransactionID xidTransactionID) throws Exception {
> final TransactionManager transactionManager = this.ejbRemoteTransactionsRepository.getTransactionManager();
> final Transaction alreadyCreatedTx = this.ejbRemoteTransactionsRepository.getImportedTransaction(xidTransactionID);
> if (alreadyCreatedTx != null) {
> // resume the already created tx
> transactionManager.resume(alreadyCreatedTx);
> } else {
> // begin a new tx and add it to the tx repository
> // TODO: Fix the tx timeout (which currently is passed as 300 seconds)
> final Transaction newSubOrdinateTx = this.ejbRemoteTransactionsRepository.importTransaction(xidTransactionID, 300);
> // associate this tx with the thread
> transactionManager.resume(newSubOrdinateTx);
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (JGRP-1826) Discovery: file-based discovery protocols should not send discovery requests
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1826?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1826.
----------------------------
Resolution: Done
> Discovery: file-based discovery protocols should not send discovery requests
> ----------------------------------------------------------------------------
>
> Key: JGRP-1826
> URL: https://issues.jboss.org/browse/JGRP-1826
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> When a node stores its information in a directory ({{FILE_PING}}, {{S3_PING}} or {{GOOGLE_PING}}), then we can optimize discovery by implementing a few things:
> * After reading all files, we send each node (represented by a file) a discovery request. That node processes the request and sends back a discovery response. This is unneeded traffic, especially with large clusters. Instead
> ** Read all files and add the information read from the files into the local caches (logical_addr_cache, UUID cache etc). This is the same as processing discovery responses from all members
> * Determine the coordinators directly from the file information. Perhaps we could even create a special file which contains information about the coordinator.
> ** This would prevent partitions from happening when starting up a large number of nodes: as long as that special file exists, nobody else will take ownership of it. When the coord leaves or crashes, we atomically replace the special file
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (JBMESSAGING-1953) Queue's not supposed to be durable
by Theo Burden (JIRA)
Theo Burden created JBMESSAGING-1953:
----------------------------------------
Summary: Queue's not supposed to be durable
Key: JBMESSAGING-1953
URL: https://issues.jboss.org/browse/JBMESSAGING-1953
Project: JBoss Messaging
Issue Type: Feature Request
Components: JMS Destination Manager, Messaging Core
Reporter: Theo Burden
Feedback on https://access.redhat.com/site/documentation/en-US/Red_Hat_JBoss_Fuse/6.0...
I want to point out what looks to me as a discrepancy.
I have experience with various JMS messaging systems. The standard as I understands it is:
Queues - the first subscriber that are able to receive the message will get it and only one subscriber. This normally makes queues by default durable as messages will stay on the queue till it has been received.
Topics is by default non-durable as a registered subscriber is needed to receive the message. If the subscriber is off-line for some reason the message will be deleted, unless it is marked as durable. As soon as all subscribers have received the message it will be deleted. This I know as I developed systems that made use of this functionality.
This is also stated in the JBoss_Enterprise_Application_Platform-6-Administration_and_Configuration_Guide-en-US on page 287. It is also in the above mentioned web-doc.
In the JBoss training and in the Admin Console, this is contradicted as the Durable option is only listed under the Queues page and not under the Topics page. This does not make any sense as stated before. I am about to write the EX248 exam and it bothers me that I have to use a feature incorrectly and in a non-standard way.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (DROOLS-437) Kie :: Camel - ClassCast exception in PreCxfTransportSoapProcessor class
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-437?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-437:
------------------------------------------------
Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1095980|https://bugzilla.redhat.com/show_bug.cgi?id=1095980] from MODIFIED to ON_QA
> Kie :: Camel - ClassCast exception in PreCxfTransportSoapProcessor class
> ------------------------------------------------------------------------
>
> Key: DROOLS-437
> URL: https://issues.jboss.org/browse/DROOLS-437
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Environment: java version "1.7.0_51"
> Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
> on application server:
> JBoss AS 7.1.1.Final "Brontes"
> running on:
> Distributor ID: Ubuntu
> Description: Ubuntu 12.04.4 LTS
> Release: 12.04
> Codename: precise
> Reporter: Jurij Kovacic
> Assignee: Edson Tirelli
> Labels: apache, camel
> Fix For: 6.1.0.Beta4
>
>
> After sending a test SOAP request to (compiled) "Drools Camel server example" from "droolsjbpm-integration-master/drools-camel-server-example", running on JBoss7 application server, the following exception occurs:
> ...
> java.lang.ClassCastException: org.apache.cxf.binding.soap.SoapMessage cannot be cast to java.lang.String
> at org.kie.jax.soap.PreCxfTransportSoapProcessor.process(PreCxfTransportSoapProcessor.java:36) [kie-camel-6.0.1.Final.jar:6.0.1.Final]
> ...
> I used the following patch (hack), to make the example work:
> diff --git a/kie-camel/src/main/java/org/kie/jax/soap/PreCxfTransportSoapProcessor.java b/kie-camel/src/main/java/or
> index c646f97..39e2afc 100644
> --- a/kie-camel/src/main/java/org/kie/jax/soap/PreCxfTransportSoapProcessor.java
> +++ b/kie-camel/src/main/java/org/kie/jax/soap/PreCxfTransportSoapProcessor.java
> @@ -33,8 +33,10 @@ public class PreCxfTransportSoapProcessor
> Map<String, Object> headers = exchange.getIn().getHeaders();
> MimeHeaders mimeHeaders = new MimeHeaders();
> for ( String header : headers.keySet() ) {
> - mimeHeaders.addHeader( header,
> - (String) headers.get( header ) );
> + // hack for avoiding uncaught exceptions when SOAP message is typecast to string
> + try { mimeHeaders.addHeader( header, (String) headers.get( header ) );}
> + catch(ClassCastException e){}
> +
> }
> SOAPMessage soapMessage = MessageFactory.newInstance().createMessage( mimeHeaders,
> is );
> It seems to me that the call to:
> ...
> exchange.getIn().getHeaders()
> ...
>
> apart from valid MIME headers, such as host, content-type etc also (wrongly?) returns the entire SOAP request object, which then cannot be typecast to string.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (DROOLS-469) NoSuchMethodError at runtime while comparing org.joda.time.DateTime instances
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-469?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-469:
------------------------------------------------
Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1094397|https://bugzilla.redhat.com/show_bug.cgi?id=1094397] from MODIFIED to ON_QA
> NoSuchMethodError at runtime while comparing org.joda.time.DateTime instances
> -----------------------------------------------------------------------------
>
> Key: DROOLS-469
> URL: https://issues.jboss.org/browse/DROOLS-469
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Environment: OS: Macosx 10.9.2
> Java version: 1.6.0_65, vendor: Apple Inc.
> Reporter: Davide Angelocola
> Assignee: Mario Fusco
> Fix For: 6.1.0.Beta4
>
>
> Given the following rule:
> ---
> import org.joda.time.DateTime;
> rule "in the past"
> when
> exists DateTime( this < new DateTime() )
> then
> System.out.println("in the past");
> end
> ---
> I obtain this exception at runtime while comparing a large number of DateTimes:
> // java.lang.NoSuchMethodError: org.joda.time.DateTime.compareTo(Lorg/joda/time/DateTime;)I
> // at ConditionEvaluatorc959ae5f82e8456f9e4f2d8b7e07b19d.evaluate(Unknown Source)
> // at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
> // at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
> // at org.drools.core.phreak.PhreakFromNode.checkConstraintsAndPropagate(PhreakFromNode.java:298)
> // at org.drools.core.phreak.PhreakFromNode.doLeftInserts(PhreakFromNode.java:101)
> // at org.drools.core.phreak.PhreakFromNode.doNode(PhreakFromNode.java:49)
> // at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:348)
> // at org.drools.core.phreak.RuleNetworkEvaluator.doRiaNode(RuleNetworkEvaluator.java:604)
> // at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:528)
> // at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334)
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months