December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1162) Why isn't the admin page a regular page?

by Chris Laprun (JIRA)

Why isn't the admin page a regular page? ---------------------------------------- Key: JBPORTAL-1162 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1162 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.DR1 Reporter: Chris Laprun Assigned To: Julien Viet Fix For: 2.6.Alpha1 and why do the other pages disappear when looking at the admin console i.e. I'm not sure we want to play hide & seek with tabs... -- 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

19 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-592) Problem with WorkingMemory serialization

by Edson Tirelli (JIRA)

Problem with WorkingMemory serialization ---------------------------------------- Key: JBRULES-592 URL: http://jira.jboss.com/jira/browse/JBRULES-592 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 3.0.5, 3.0.4, 3.0.3, 3.0.2, 3.0.1, 3.0 Reporter: Edson Tirelli Assigned To: Edson Tirelli Fix For: 3.1-m1, 3.0.5 REPORTED BY MICHAEL SUZIO: ----------------------------------------------- I've run into a problem. Strangely enough, I swear this worked in the past, but then we went into a long coding phase and emerged from it to find out our test cases didn't actually work "in the wild". Took some time, but eventually I figured out the why of that -- and coded better tests. In any case, here is what is happening: - We create a rulebase from some DRL text (doesn't matter how it gets created, my test code below is *one* example case) - A Working Memory object is created: WorkingMemory wm =3D3D3D rulebase.newWorkingMemory(); - The WorkingMemory is serialized to disk via normal ObjectOutputStream methods Now, *while the VM is running*, I can create new RuleBase objects, read that WorkingMemory back in, and attach it to those new RuleBase objects, and it always works. However, if I stop the VM, and re-run the sample program below, it fails with this stack trace: java.lang.ClassNotFoundException: [Lorg.drools.reteoo.ObjectTypeNode; at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass (ClassLoader.java:251) at org.drools.rule.CompositePackageClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.drools.common.ObjectInputStreamWithLoader.resolveClass (Unknown Source) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466) at java.io.ObjectInputStream.readArray (ObjectInputStream.java:1591) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at java.util.HashMap.readObject (HashMap.java:1067) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946) at java.io.ObjectInputStream.readSerialData (ObjectInputStream.java:1809) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719 ) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readArray (ObjectInputStream.java:1634) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1634) at java.io.ObjectInputStream.readObject0 (ObjectInputStream.java:1299) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832) at java.io.ObjectInputStream.readOrdinaryObject (ObjectInputStream.java:1719 ) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908) at java.io.ObjectInputStream.readSerialData (ObjectInputStream.java:1832) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719 ) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.defaultReadFields (ObjectInputStream.java:1908) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719 ) at java.io.ObjectInputStream.readObject0 (ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at org.drools.common.AbstractRuleBase.newWorkingMemory(Unknown Source) at org.drools.common.AbstractRuleBase.newWorkingMemory (Unknown Source) at DroolsFailureTest.runTest(DroolsFailureTest.java:52) at DroolsFailureTest.main(DroolsFailureTest.java:25) So, it appears that WorkingMemory objects cannot (at least for me in this case) be serialized, then read back into a new VM. That always fails, and it's quite vexing. Our intention is to be running rules on large amounts of data that periodically come in, and we need to save our progress as we go along and be able to restore that data anywhere in the data cluster that the job gets parceled out to (so, ultimately, the WorkingMemory data is going to go into a database or possibly get written out to a shared filesystem among the drones). If I can't save/restore data transparently between runs, this is pretty much a show-stopper. Technical details: Java 1.5.0_10 (but I tested this on 1.5.0_04, 1.5.0_06, 1.5.0_08, and 1.5.0_09 -- basically, whatever we had available on other people's workstations), all on Windows boxes. JBoss Rules 3.0.3 and 3.0.5 both seemed to fail consistently. Here is the sample code (it's two classes, save them to appropriate files). I think these should be reproducible cases. Run the DroolsFailureTest twice, and it will work the first time (showing that reads/writes within the VM work), and then fail the second time it is run (when the cached WorkingMemory on disk then is getting read back into a new VM). import java.io.*; import org.drools.*; import org.drools.compiler.*; public class DroolsFailureTest { public static void main(String[] args) { boolean removeFile = false; if (args.length > 0) { removeFile = args[0].equalsIgnoreCase("remove"); } if (removeFile) { WorkingMemorySaver memSaver = getWorkingMemorySaver(); memSaver.clearWorkingMemory(); } runTest(); // run 1 -- should always work runTest(); // run 2 -- fails? System.exit(0); } public static void runTest() { System.out.println ("Getting working memory handler"); WorkingMemorySaver memSaver = getWorkingMemorySaver(); RuleBase rb = getRuleBase(); // Uncomment this -- prove we get a different RuleBase object // each time // // System.err.println("Rulebase hashcode = " + rb); InputStream is = memSaver.getWorkingMemoryInputStream(); System.out.println("Got input stream " + is); WorkingMemory wm = null; if (is != null) { System.err.println("Trying to restore object from input stream"); try { wm = rb.newWorkingMemory(is); System.err.println("Got " + wm); } catch (Exception e) { e.printStackTrace(); } } if (wm == null) { wm = rb.newWorkingMemory(); System.err.println("No working memory, creating new one = " + wm); } System.out.println("Asserted data, running the rules"); // wm.fireAllRules(); System.err.println ("Saving working memory"); memSaver.saveWorkingMemory(wm); } private static RuleBase getRuleBase() { System.setProperty("drools.compiler", "JANINO"); RuleBaseLoader rbl = RuleBaseLoader.getInstance(); String ruleText = getRuleText(); RuleBase rb = null; try { rb = rbl.loadFromReader(new StringReader(ruleText)); } catch (CheckedDroolsException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } return rb; } private static String getRuleText() { String ruleText = "package test;\n" + "rule TestRule\n" + "when\n" + " sObj: String()\n" + "then\n" + " System.out.println(\"Saw \" + sObj);\n" + "end"; return ruleText; } private static WorkingMemorySaver getWorkingMemorySaver() { WorkingMemorySaver memSaver = new WorkingMemorySaver(); memSaver.setWorkingMemoryDir("C:\\"); return memSaver; } } import java.io.*; import org.drools.*; /** * */ public class WorkingMemorySaver { private File workingMemoryDir = null; public WorkingMemorySaver() { } public InputStream getWorkingMemoryInputStream() { File workingMemoryFile = getWorkingMemoryFile(); InputStream stream = null; if ( workingMemoryFile.exists()) { try { stream = new FileInputStream(getWorkingMemoryFile()); } catch (FileNotFoundException e) { e.printStackTrace(); } } return stream; } public void saveWorkingMemory(WorkingMemory wm) { try { //noinspection IOResourceOpenedButNotSafelCuyClosed ObjectOutputStream oStream = new ObjectOutputStream((new FileOutputStream(getWorkingMemoryFile()))); oStream.writeObject(wm); } catch (IOException e) { e.printStackTrace(); } } /** * used in case the file becomes corrupted */ public void clearWorkingMemory() { try { File workingMemoryFile = getWorkingMemoryFile(); if (workingMemoryFile != null) { boolean deleted = workingMemoryFile.delete(); if (deleted) { System.err.println("Deleted working memory file " + workingMemoryFile.getName()); } } } catch (Exception e) { e.printStackTrace(); } } public File getWorkingMemoryDir() { return workingMemoryDir; } public void setWorkingMemoryDir(File workingMemoryDir) { this.workingMemoryDir = workingMemoryDir; } public void setWorkingMemoryDir(String workingMemoryDirName) { this.workingMemoryDir = new File(workingMemoryDirName); } private File getWorkingMemoryFile() { return new File(workingMemoryDir, "working_memory.bin"); } } A possible related bug is in this thread: http://www.mail-archive.com/user@drools.codehaus.org/msg01731.html Which points out this Sun bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D3D3D6434149 In fact, it looks like my problem is just a variant on Raffael's. Like Raffael, I've tried JBoss 3.0.5 (no help) and Java 1.6 (similar results -- different "stream corrupted" error in my case, but essentially the same). I don't see a resolution to his bug on the archives -- Raffael, did you find a fix? Please let me know! Sorry for such a long post, but I hope someone can point out what I can do to fix this issue. -- 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

19 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-682) JBoss Messagin Ant Installer does not overwrite jboss-remoting.jar in server/messaging/lib

by Takaaki Igarashi (JIRA)

JBoss Messagin Ant Installer does not overwrite jboss-remoting.jar in server/messaging/lib ------------------------------------------------------------------------------------------ Key: JBMESSAGING-682 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-682 Project: JBoss Messaging Issue Type: Bug Components: Configuration and Management Affects Versions: 1.0.1.SP2 Reporter: Takaaki Igarashi Assigned To: Ovidiu Feodorov Priority: Optional The following exception and Errors occures when using JBoss Messaging from remote. (SocketClientInvoker.java:transport:293) -Got marshalling exception, exiting (JBossConnectionFactory.java:ensureAOPConfigLoaded:250) -Failed to config client side AOP Failed to config client side AOP The cause is version of jboss-remoting.jar in server/messaging/lib and server/messaging/deploy are different. The ant script that comes with JBoss Messaging does not overwrite jboss-remoting.jar in server/messaging/lib. -- 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

19 years, 5 months

3
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-795) Classloader problems replicating custom classes with JBoss Cache as 2nd level cache

by Brian Stansberry (JIRA)

Classloader problems replicating custom classes with JBoss Cache as 2nd level cache ----------------------------------------------------------------------------------- Key: EJBTHREE-795 URL: http://jira.jboss.com/jira/browse/EJBTHREE-795 Project: EJB 3.0 Issue Type: Bug Components: Clustering Affects Versions: EJB 3.0 RC9 - FD Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: EJB 3.0 RC10 - FD Container issue for tracking JBCLUSTER-150 related activities in the EJB3 project. See JBCLUSTER-150 and the forum thread for details. Basically, problems occur replicating user classes used as fields in entities when JBoss Cache is used as the 2nd level cache and a scoped classloader is used. -- 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

19 years, 5 months

2
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-735) Append the cluster name to the TreeCache log category

by Brian Stansberry (JIRA)

Append the cluster name to the TreeCache log category ----------------------------------------------------- Key: JBCACHE-735 URL: http://jira.jboss.com/jira/browse/JBCACHE-735 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 2.1.0 For the org.jboss.cache.TreeCache class (and PojoCache as well) it would be good to include the cluster name in the log category. This would help a lot in log analysis in situations where there are multiple caches. -- 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

19 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBPM-780) document how to replace hashtable with ehcache cacheprovider

by Tom Baeyens (JIRA)

document how to replace hashtable with ehcache cacheprovider ------------------------------------------------------------ Key: JBPM-780 URL: http://jira.jboss.com/jira/browse/JBPM-780 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Reporter: Tom Baeyens Assigned To: Tom Baeyens Fix For: jBPM 3.2 alpha 3 -- 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

19 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBXB-89) JBossXB automatically unzips gzipped content when decoding base64 data.

by Darran Lofthouse (JIRA)

JBossXB automatically unzips gzipped content when decoding base64 data. ----------------------------------------------------------------------- Key: JBXB-89 URL: http://jira.jboss.com/jira/browse/JBXB-89 Project: JBoss XML Binding (JBossXB) Issue Type: Bug Affects Versions: JBossXB-1.0.0.CR7 Reporter: Darran Lofthouse Fix For: JBossXB-1.0 JBossXB automatically unzips gzipped content when decoding base64 data. The reason why it is automatically unzipped is becuase the method unmarshalBase64 in org.jboss.xb.binding.SimpleTypeBindings is calling the method decode in org.jboss.util.Base64, this decode method after converting from Base64 detects that it is gzipped so unzippes it. If we do not need to unzip the data we could call the decode method that takes the byte array instead of a String as this does not perform any unzipping. -- 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

19 years, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (JBPORTAL-946) Window changes in admin ui not immediate

by Roy Russo (JIRA)

Window changes in admin ui not immediate ---------------------------------------- Key: JBPORTAL-946 URL: http://jira.jboss.com/jira/browse/JBPORTAL-946 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.4 Final Reporter: Roy Russo Assigned To: Julien Viet Moving windows via the ui do not register immediatley when the page refreshes. You must log in again to see the changes. -- 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

19 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-3721) Clustered SSO entries not properly cleaned up if a server crashes

by Brian Stansberry (JIRA)

Clustered SSO entries not properly cleaned up if a server crashes ------------------------------------------------------------------ Key: JBAS-3721 URL: http://jira.jboss.com/jira/browse/JBAS-3721 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.0.5.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-4.0.6.CR1 If a server crashes, the entries for its sessions in the clustered sso cache will never be removed, and thus the sso may never be removed. TreeCacheSSOManager needs to listen for view changes and discard sessions associated with dead servers. -- 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

19 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-640) Implement an asynchronous method for handling callbacks.

by Ron Sigal (JIRA)

Implement an asynchronous method for handling callbacks. -------------------------------------------------------- Key: JBREM-640 URL: http://jira.jboss.com/jira/browse/JBREM-640 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta1 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.0.Beta1 (Bluto) Tim Fox: Currently, it's my understanding that push callbacks (using socket transport anyway) are synchronous, i.e. the server side thread that executes the callback blocks until the callback has been delivered to the client side and returned. Is it currrently possible to execute asynch push callbacks? I.e. the thread that calls the callback returns immediately once it has registered the callback with remoting. And it is then delivered on a different thread? Ideally executing using some kind of executor (e.g. PooledExecutor) with a bounded queue size which blocks when it is full would be ideal. -- 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

19 years, 5 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 December 2006