March 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-1415) Certain uses of from causes NullPointerException in WorkingMemoryLogger

by Mattias Nilsson (JIRA)

Certain uses of from causes NullPointerException in WorkingMemoryLogger ----------------------------------------------------------------------- Key: JBRULES-1415 URL: http://jira.jboss.com/jira/browse/JBRULES-1415 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.3 Reporter: Mattias Nilsson This rule causes a NullPointerException when WorkingMemoryFileLogger is activated. Without the logger the rule works fine. rule "TestRule" when A( theList : list ) B( theName : name ) from theList then System.out.println( "ok" ); end Seems to be the assigning of variable theName that causes the problem. If i remove "theName : name" there is no NullPointerException. Here is the stack trace: java.lang.NullPointerException at org.drools.base.com.sample.DroolsTest$B15799300$getName.getValue(Unknown Source) at org.drools.base.ClassFieldExtractor.getValue(ClassFieldExtractor.java:127) at org.drools.rule.Declaration.getValue(Declaration.java:197) at org.drools.audit.WorkingMemoryLogger.extractDeclarations(WorkingMemoryLogger.java:267) at org.drools.audit.WorkingMemoryLogger.activationCreated(WorkingMemoryLogger.java:201) at org.drools.event.AgendaEventSupport.fireActivationCreated(AgendaEventSupport.java:75) at org.drools.reteoo.RuleTerminalNode.assertTuple(RuleTerminalNode.java:331) . . . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

2
6
0 / 0

[JBoss JIRA] Created: (JBRULES-1502) update example to use modify block as default

by Fernando Meyer (JIRA)

update example to use modify block as default --------------------------------------------- Key: JBRULES-1502 URL: http://jira.jboss.com/jira/browse/JBRULES-1502 Project: JBoss Drools Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.0.4 Reporter: Fernando Meyer Assigned To: Fernando Meyer Fix For: 4.0.5, 5.0.0-M1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBREM-167) RMI Invoker does not use true remoting marshalling/unmarshalling

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-167?page=all ] Ron Sigal closed JBREM-167. --------------------------- Resolution: Done Tests pass in hudson. > RMI Invoker does not use true remoting marshalling/unmarshalling > ---------------------------------------------------------------- > > Key: JBREM-167 > URL: http://jira.jboss.com/jira/browse/JBREM-167 > Project: JBoss Remoting > Issue Type: Bug > Components: transport > Affects Versions: 1.2.0 final > Reporter: Tom Elrod > Assigned To: Ron Sigal > Priority: Minor > Fix For: 2.4.0.CR1 (Pinto) > > > In process of fixing JBREM-165 (RMI support for UnifiedInvoker), have added ability to call on mashaller when making request so that can modify payload before sending. Although the RMIInvokerClient does use the configured marshaller, it does not use the configured unmarshaller (RMIInvokerServer is the opposite). This was done to get JBREM-165 working, but is not a total solution and needs to be fixed so anyone can add a marshaller/unmarshaller for RMI invoker that will be called both ways (in and out) on both the client and server. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-927) Adjust content length when CompressingUnMarshaller wraps HTTPUnMarshaller

by Ron Sigal (JIRA)

Adjust content length when CompressingUnMarshaller wraps HTTPUnMarshaller ------------------------------------------------------------------------- Key: JBREM-927 URL: http://jira.jboss.com/jira/browse/JBREM-927 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta2 (Pinto), 2.2.2.SP4 Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Minor Fix For: 2.4.0.CR1 (Pinto) When org.jboss.remoting.marshal.compress.CompressingUnMarshaller wraps org.jboss.remoting.marshal.http.HTTPUnMarshaller, and the payload is a String, then HTTPUnMarshaller can be mislead by the value of content-length, which is the length of the compressed payload rather than the number of bytes HTTPUnMarshaller should read. Reported by Alex on forum. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1221) EJB 2.1 view throws wrong exception if object can not be removed

by Carlo de Wolf (JIRA)

EJB 2.1 view throws wrong exception if object can not be removed ---------------------------------------------------------------- Key: EJBTHREE-1221 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1221 Project: EJB 3.0 Issue Type: Bug Reporter: Carlo de Wolf EJB 3 4.4 bullet 13: If the EJB 2.1 client view is used, any subsequent attempt causes the java.rmi.NoSuchObjectException to be thrown if the client is a remote client, or the javax.ejb.NoSuchObjectLocalException if the client is a local client. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1218) Removing a non-existant SFSB does not throw NoSuchEJBException (EJB 3 4.4 bullet 13)

by Carlo de Wolf (JIRA)

Removing a non-existant SFSB does not throw NoSuchEJBException (EJB 3 4.4 bullet 13) ------------------------------------------------------------------------------------ Key: EJBTHREE-1218 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1218 Project: EJB 3.0 Issue Type: Bug Reporter: Carlo de Wolf Fix For: AS 5.0.0.CR1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-662) max_bundle_size checks should only happen when bundling is enabled (either via conf file or JMX)

by Galder Zamarreno (JIRA)

max_bundle_size checks should only happen when bundling is enabled (either via conf file or JMX) ------------------------------------------------------------------------------------------------ Key: JGRP-662 URL: http://jira.jboss.com/jira/browse/JGRP-662 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1 SP4 Reporter: Galder Zamarreno Assigned To: Bela Ban If enable_bundling is disabled (false), why does JGroups read max_bundle_size and max_bundle_timeout values? These max values are used within TP.Blunder but this is not created if bundling is disabled. JGroups should only read and make the necessary processing for max_bundle_size and max_bundle_timeout if bundling is enabled. I@ll fill in a JIRA for this. Seems like bundling could be enabled via dynamically via JMX (TPMBean). Maybe at this point JGroups should read the values from the configuration file. Alternatively, values could have already been read even if bundling was disabled, but calls like this in TP.setProperties: if(bundle_size > max_bundle_size) { if(log.isErrorEnabled()) log.error("max_bundle_size (" + bundle_size + ") is greater than largest TP fragmentation size (" + max_bundle_size + ')'); return false; } Should only happen if bundling was enabled either statically or dynamically via the MBean, specially since max_bundle_size value comes from a attempt to guess the maximum size of a Datagram packet by sending one, which is dynamic value that could change over time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

3
4
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1932) PortletSession Replication failing

by Thomas Heute (JIRA)

PortletSession Replication failing ---------------------------------- Key: JBPORTAL-1932 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1932 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.4 Final Reporter: Thomas Heute Assigned To: Julien Viet Fix For: 2.6.5 Final Portlet session replication is failing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1216) Core Depends on Itself in dependency:copy

by Andrew Lee Rubinger (JIRA)

Core Depends on Itself in dependency:copy ----------------------------------------- Key: EJBTHREE-1216 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1216 Project: EJB 3.0 Issue Type: Bug Components: core Reporter: Andrew Lee Rubinger Assigned To: Andrew Lee Rubinger Fix For: AS 5.0.0.CR1 [INFO] ---------------------------------------------------------------------------- [INFO] Building JBoss EJB 3.0 Core [INFO] task-segment: [install] [INFO] ---------------------------------------------------------------------------- [INFO] snapshot org.jboss.ejb3:maven-jboss-ejb3-testrunner-plugin:0.1.0-SNAPSHOT: checking for updates from jboss-snapshots [INFO] artifact org.apache.maven.plugins:maven-antrun-plugin: checking for updates from jboss [INFO] artifact org.apache.maven.plugins:maven-dependency-plugin: checking for updates from jboss [INFO] snapshot org.jboss:jboss-test:1.0.5-SNAPSHOT: checking for updates from jboss-snapshots [INFO] [jboss-ejb3-testrunner:run-tests {execution: run-ejb3-tests}] [INFO] Skipping integration tests, to enable set "jboss.test.skip" to false. [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [dependency:unpack {execution: unpack-build-scripts}] [INFO] Configured Artifact: org.jboss:jboss-test:?:jar [INFO] jboss-test-1.0.5.GA.jar already unpacked. [INFO] [dependency:copy {execution: copy-jboss-test}] [INFO] Configured Artifact: org.jboss:jboss-test:?:jar [INFO] org.jboss:jboss-test:1.0.5.GA:jar already exists in /home/carlo/work/ejb3/core/target/dependencies/lib [INFO] [dependency:copy {execution: copy-core-dependencies}] [INFO] Configured Artifact: org.jboss.cache:jbosscache-core:?:jar [INFO] Configured Artifact: org.jboss.ejb3:jboss-ejb3-core:?:jar [INFO] snapshot org.jboss.ejb3:jboss-ejb3-core:0.1.0-SNAPSHOT: checking for updates from jboss-snapshots Downloading: http://snapshots.jboss.org/maven2/org/jboss/ejb3/jboss-ejb3-core/0.1.0-SN... 856K downloaded Bound to the build lifecycle is a dependency:copy task that throws a bunch of stuff in "target/dependencies/lib" (for use on the client CP, especially for Unit Tests), and core is defined here. So it depends on itself, but actually...it depends on the version of itself in a Maven repo (either local or remote). Get rid of this; Unit Tests CP is pointed to proper version of core artifacts in "target". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1211) Fix Server Shutdown Detection in TestSuite

by Andrew Lee Rubinger (JIRA)

Fix Server Shutdown Detection in TestSuite ------------------------------------------ Key: EJBTHREE-1211 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1211 Project: EJB 3.0 Issue Type: Task Reporter: Andrew Lee Rubinger Assigned To: Andrew Lee Rubinger Fix For: AS 5.0.0.CR1 Hudson runs (particularly ejb3-ssl now) often (if not all the time) fail due to the testrunner not sensing when a server has shut down. Current implementation searches for a shutdown String in the server log: <contains text="[org.jboss.bootstrap.microcontainer.ServerImpl] (JBoss Shutdown Hook) Shutdown complete"/> ...and even though this is present: 2008-03-10 11:36:27,643 INFO [org.jboss.bootstrap.microcontainer.ServerImpl] (JBoss Shutdown Hook) Shutdown complete ...the script times out with a failure. Fix this and get The Hudson runs finishing reliably. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
1
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 March 2008