November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-1060) Unexpected exit with no stack trace or other information

by christopher barham (JIRA)

Unexpected exit with no stack trace or other information -------------------------------------------------------- Key: JBRULES-1060 URL: http://jira.jboss.com/jira/browse/JBRULES-1060 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.0.GA Environment: Windows XP sp2, 1GB RAM, Sun Java JDK 1.5.0_11, Eclipse 3.3 Build id: I20070621-1340, JBOSS Rules feature/plugin 4.0.0 Reporter: christopher barham Assigned To: Mark Proctor When inserting a number of facts, (seems to be somewhere around 450 facts in this test example here), the rules system exits unexpectedly with no stack trace or other information. I pared down my code to a simple example that demonstrates this below. I can get it to run normally if I insert 450 facts, however 475 or above exhibits this unexpected system exit. I am running this from Eclipse. Garbage.java (fact bean): package com.sample; public class Garbage { private char id; private int someNumber; public Garbage(char garbageId, int someNumber) { setSomeNumber(someNumber); setId(garbageId); } public char getId() { return id; } public int getSomeNumber() { return someNumber; } public void setId(char id) { this.id = id; } public void setSomeNumber(int someNumber) { this.someNumber = someNumber; } @Override public String toString() { StringBuilder sb = new StringBuilder(); sb.append("a Garbage { "); sb.append("someNumber= "); sb.append(getSomeNumber()); sb.append(", id= "); sb.append(getId()); sb.append(" }"); return sb.toString(); } } StrangeExit.Java (Rule Engine startup and fact insertion): package com.sample; import java.io.InputStreamReader; import java.io.Reader; import org.drools.RuleBase; import org.drools.RuleBaseFactory; import org.drools.WorkingMemory; import org.drools.compiler.PackageBuilder; import org.drools.event.DebugWorkingMemoryEventListener; import org.drools.rule.Package; public class StrangeExit { public static final void main(String[] args) { try { long startTime = System.currentTimeMillis(); System.out.println("Starting problem at " + new java.util.Date()); RuleBase ruleBase = readRule(); WorkingMemory workingMemory = ruleBase.newStatefulSession(); workingMemory.addEventListener(new DebugWorkingMemoryEventListener()); assertAllFacts(workingMemory); workingMemory.fireAllRules(); long stopTime = System.currentTimeMillis(); long runTime = stopTime - startTime; System.out.println("Run time (milliseconds): " + runTime); System.out.println("Finished problem at " + new java.util.Date()); } catch (Throwable t) { t.printStackTrace(); } } private static void assertAllFacts(WorkingMemory workingMemory) { for (int i = 1; i <= 3; i++) { for (int j = 1; j <= 475; j++) { Garbage gar = new Garbage((char)(i + 64), j); workingMemory.insert(gar); } } } private static RuleBase readRule() throws Exception { Reader source = new InputStreamReader(StrangeExit.class.getResourceAsStream("/strange.drl")); PackageBuilder builder = new PackageBuilder(); builder.addPackageFromDrl(source); Package pkg = builder.getPackage(); RuleBase ruleBase = RuleBaseFactory.newRuleBase(); ruleBase.addPackage(pkg); return ruleBase; } } The Rule itself: package com.sample import com.sample.Garbage; rule "Weird exit with no stack trace error" when $garA : Garbage( ) $garB : Garbage( id == 'B' , someNumber >= $garA.someNumber ) then System.out.println("Something is up"); end -- 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

16 years, 10 months

4
10
0 / 0

[JBoss JIRA] Created: (JBRULES-1338) DirectoryScanner should only take into account relevant files

by Jￃﾶrg Erdmenger (JIRA)

DirectoryScanner should only take into account relevant files ------------------------------------------------------------- Key: JBRULES-1338 URL: http://jira.jboss.com/jira/browse/JBRULES-1338 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: All Reporter: Jￃﾶrg Erdmenger Currently DirectoryScanner in its configure and loadPackageChanges methods takes into account all types of files and hands them to FileScanner. This causes issues when the directory specified is under source management control (at least if CVS or Subversion are used) as the .svn or similar files/dirs cause FileScanner to barf. Now I'm sure that for plenty of cases the dir passed to DirectoryScanner won't be SCM managed but I think there might also be lots of situations where it is. Considering that it would be such a trivial change to either: - only take into account .pkg and .drl files (or do we need .dsl, .rf as well) - or at least ignore dot files (and maybe directories in general?) I think it will be worth doing. -- 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

16 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-1225) allow dump of generated .java files during rule compilation

by Godmar Back (JIRA)

allow dump of generated .java files during rule compilation ----------------------------------------------------------- Key: JBRULES-1225 URL: http://jira.jboss.com/jira/browse/JBRULES-1225 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.0.1 Reporter: Godmar Back Assigned To: Mark Proctor Please add an option to dump the generated .java code. Otherwise, debugging compile errors is a night mare. Even when dialect "MVEL" isn't used, some expression seem to become MVEL expressions. In addition, it seems that bean-Syntax (as in x.prop) can be used in the conditions of a rule, but the consequence requires that you use x.getProp()). It's also not clear in which scope/package/class the generated code lives. -- 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

16 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1121) Allow command line configuration of ServerPeerID

by Brian Stansberry (JIRA)

Allow command line configuration of ServerPeerID ------------------------------------------------ Key: JBMESSAGING-1121 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1121 Project: JBoss Messaging Issue Type: Feature Request Components: JMS Clustering Affects Versions: 1.4.0.GA Reporter: Brian Stansberry Assigned To: Tim Fox Fix For: AS 5.0 Integration, EAP 4.3 Integration The ServerPeer ServerPeerID is currently hard coded at 0 in messaging-service.xml. If you want to set up a cluster, the only way to get it to work is to manually change the value in that file in each node. This needs to be configurable from the command line; i.e via system property substitution. Need to be sure any changes made in the messaging-service.xml are also reflected in docs/examples/binding-manager/sample-bindings.xml. -- 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

16 years, 10 months

4
13
0 / 0

[JBoss JIRA] Created: (JBSER-98) Write slot with fields only if both readObject and writeObject are missing

by Galder Zamarreno (JIRA)

Write slot with fields only if both readObject and writeObject are missing -------------------------------------------------------------------------- Key: JBSER-98 URL: http://jira.jboss.com/jira/browse/JBSER-98 Project: JBoss Serialization Issue Type: Feature Request Affects Versions: 1.0.3 GA Reporter: Galder Zamarreno Assigned To: Clebert Suconic Over the last few weeks, I've been dealing with a funky support case which showed the following stacktrace: ... Caused by: org.jboss.serial.exception.SerializationException: Excepted to be String at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readUTF(DataContainer.java:1120) at org.jboss.serial.classmetamodel.StreamingClass.readStream(StreamingClass.java:71) at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:381) at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82) at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:845) at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353) at org.jboss.serial.persister.RegularObjectPersister.defaultRead(RegularObjectPersister.java:273) at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:241) at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:412) at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82) at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readObject(DataContainer.java:845) at org.jboss.serial.io.MarshalledObjectForLocalCalls.get(MarshalledObjectForLocalCalls.java:60) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102) ... 28 more Caused by: java.lang.ClassCastException: org.jboss.serial.finalcontainers.IntegerContainer at org.jboss.serial.objectmetamodel.DataContainer$DataContainerInput.readUTF(DataContainer.java:1116) ... 42 more The cause of the issue was that the customer had a class where it had re-implemented readObject(java.io.ObjectInputStream stream) but had not re-implemented writeObject(java.io.ObjectOutputStream stream). This is obviously a programming error on their side, but it took a while to detect such stupid mistake. The problem within JBoss Serialization was that because this class didn't have a writeObject() reimplementation, it was a writing the class as a slot with fields, but when it came to reading it, it was reading the class as a slot with method because readObject had been reimplemented. The next time a slot with fields was read, the fields were mixed up. To avoid these type of situations, I'd suggest that: - JBS only writes as fields if *both* writeObject and readObject are missing. Right now, can't see a situation where you'd implement one and not the other, thoughts? -- 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

16 years, 10 months

1
4
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-198) jboss-kernel and jboss-aop-mc-int have compile dependencies on jboss-test and junit

by Elias Ross (JIRA)

jboss-kernel and jboss-aop-mc-int have compile dependencies on jboss-test and junit ----------------------------------------------------------------------------------- Key: JBMICROCONT-198 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-198 Project: JBoss MicroContainer Issue Type: Task Reporter: Elias Ross jboss-test (and its dependencies) and junit are pulled into projects that depend on "jboss-kernel" and "jboss-aop-mc-int" because the project contains child classes of TestCase within src/main/java ... Probably the best way to deal with this is to create a separate jboss-kernel-test and mc-int-test artifacts. These dependencies pull in: junit\junit\4.1\junit-4.1.jar jboss\profiler\jvmti\jboss-profiler-jvmti\1.0.0.CR5\jboss-profiler-jvmti-1.0.0.CR5.jar jboss\jboss-test\1.0.4-SNAPSHOT\jboss-test-1.0.4-SNAPSHOT.jar which aren't relevant to people's runtime. -- 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

16 years, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAOP-492) Duplicate _getAdvisor

by Flavia Rainone (JIRA)

Duplicate _getAdvisor --------------------- Key: JBAOP-492 URL: http://jira.jboss.com/jira/browse/JBAOP-492 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR1 Reporter: Flavia Rainone Users are getting the following error message: AOP Instrumentor failed to transform com.radware.insite.model.trafficredirection.farm.profile.FarmProfile _$$_javassist_233 16:09:12,066 ERROR [STDERR] javassist.bytecode.DuplicateMemberException: duplicate method: _getAdvis or in com.radware.insite.model.trafficre This bug has been reproduced when using Hibernate with JBoss AOP. Refer to the forum link for more information. -- 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

16 years, 10 months

4
10
0 / 0

[JBoss JIRA] Created: (JBAS-4434) Create tests of file locking in the deploy dir

by Brian Stansberry (JIRA)

Create tests of file locking in the deploy dir ---------------------------------------------- Key: JBAS-4434 URL: http://jira.jboss.com/jira/browse/JBAS-4434 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Brian Stansberry Need simple tests where different sorts of deployments are copied to deploy, allowed to deploy, and then deleted. Intent is to prove that the file in the deploy dir can be deleted; i.e. the deployment process doesn't create a file lock. Most AS tests today do deployments via the RMIAdaptor, an approach that doesn't detect file lock issues. See JBAS--4415 and EJBTHREE-969 for an example of where this broke down. The FarmService tests have to use a 'copy file to farm dir' approach, so they detected a file lock issue. But this kind of problem should be directly tested so it's easier to know when problems like EJBTHREE-969 creep in. Also the FarmService test only deploys one jar; if by chance it had been a war instead of an ejb jar, the problem would not have been detected, since the JBossWeb deployer would have handled the war before accepts() was called on the Ejb3Deployer. -- 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

16 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-698) Update Remoting Marshaller/UnMarshallers to implement PreferredStreamMarshaller/PreferredStreamUnMarshaller interfaces.

by Ron Sigal (JIRA)

Update Remoting Marshaller/UnMarshallers to implement PreferredStreamMarshaller/PreferredStreamUnMarshaller interfaces. ----------------------------------------------------------------------------------------------------------------------- Key: JBREM-698 URL: http://jira.jboss.com/jira/browse/JBREM-698 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta2 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.0.Beta2 (Bluto) In response to JBREM-692 the org.jboss.remoting.marshal.PreferredStreamMarshaller and org.jboss.remoting.marshal.PreferredStreamUnMarshaller interfaces were introduced, and org.jboss.remoting.marshal.serializable.SerializableMarshaller and org.jboss.remoting.marshal.serializable.SerializableUnMarshaller were modified to implement them. In particular, they implement a getMarshallingStream() method which returns an object stream that can be cached and reused by the transport layer. Now, the other Remoting marshallers (http, compressing, encrypting) should also be made to implement those interfaces. -- 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

16 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBREM-764) Wire version should be configurable per client or server

by Ron Sigal (JIRA)

Wire version should be configurable per client or server -------------------------------------------------------- Key: JBREM-764 URL: http://jira.jboss.com/jira/browse/JBREM-764 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) Currently org.jboss.remoting.Version looks to the system property "jboss.remoting.version" to determine the value to return for Version.getDefaultVersion(), and the transports refer to Version.getDefaultVersion(). This means that all clients and servers in a JVM use the same version. It would be preferable to allow the wire version to configurable as a parameter to each 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

16 years, 10 months

1
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2007