April 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1227) problem with editing html source in cms

by Prabhat Jha (JIRA)

problem with editing html source in cms --------------------------------------- Key: JBPORTAL-1227 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1227 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.6.Alpha2 Reporter: Prabhat Jha Assigned To: Roy Russo Fix For: 2.6.Alpha2 Attachments: screenshot-1.jpg 1. Login as admin 2. Go to CMS Administration portlet 3. edit index.html with HTML source editor ( I just added my name at the end so it looks like : The JBoss Portal Team - Prabhat.</p> 4. Hit Update 5. The update version 1.1 displays "#welcomelogo { float: left; margin: 30px 0px 30px 15px; } #welcometext { margin: 30px 50px 30px 225px; } #welcomegreybox { background-color: #f4f4f4; padding: 15px; margin-bottom: 30px; } #welcomegreyboxTD { border-left: 1px solid #d5d5d5; padding-left: 15px; } #welcomegreybox h3 { color: #5078aa; font: bold 13px Helvetica, Arial, sans-serif; }" at the. This html snippet should not be displayed. I have attached the screenshot. -- 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, 3 months

5
9
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1331) Remove the CMSPortet's tight coupling to the default page and correspondingly to the /content context

by Sohil Shah (JIRA)

Remove the CMSPortet's tight coupling to the default page and correspondingly to the /content context ----------------------------------------------------------------------------------------------------- Key: JBPORTAL-1331 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1331 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.6 Final Reporter: Sohil Shah Assigned To: Sohil Shah Fix For: 2.6 Final Look into the CMSObjectCommandFactoryService and make it more flexible to deal with multiple pages and multiple contexts -- 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, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1187) Evaluate Alfresco JCR Impl for performance

by Sohil Shah (JIRA)

Evaluate Alfresco JCR Impl for performance ------------------------------------------ Key: JBPORTAL-1187 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1187 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.6.Alpha1 Reporter: Sohil Shah Assigned To: Sohil Shah Fix For: 2.6.Beta1 The currently packaged JackRabbit impl will not scale... Its a piece of crap -- 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, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-707) Move function implementation to use static imports

by Mark Proctor (JIRA)

Move function implementation to use static imports -------------------------------------------------- Key: JBRULES-707 URL: http://jira.jboss.com/jira/browse/JBRULES-707 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Drl Parser/Builder Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m2 Eclipse JDT and Janino now support static imports, while still targteting jdk1.4 byetcode. -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-619) Rule Flow Core Implementation

by Mark Proctor (JIRA)

Rule Flow Core Implementation ----------------------------- Key: JBRULES-619 URL: http://jira.jboss.com/jira/browse/JBRULES-619 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Reteoo, Rule Assemply/SPI Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m1 Implement core Rule Flow capabiltiies in drools-core. -- 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, 3 months

3
3
0 / 0

[JBoss JIRA] Created: (JBRULES-453) ruleflow

by Mark Proctor (JIRA)

ruleflow -------- Key: JBRULES-453 URL: http://jira.jboss.com/jira/browse/JBRULES-453 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Leaps, Reteoo Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-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

19 years, 3 months

3
3
0 / 0

[JBoss JIRA] Created: (JBRULES-541) Avoid WeakHashmap for tracking working memories in a RuleBase.

by Michael Neale (JIRA)

Avoid WeakHashmap for tracking working memories in a RuleBase. -------------------------------------------------------------- Key: JBRULES-541 URL: http://jira.jboss.com/jira/browse/JBRULES-541 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rule Assemply/SPI Affects Versions: 3.0.4 Reporter: Michael Neale Assigned To: Mark Proctor Priority: Critical This comes under the heading of "I knew it would happen one day and I warned people about it but they didn't listen and Michael is always right in the long run, except when he predicted that the graphical web browser would NOT take off back in 1993 and was catastrophically wrong. Someone was having issues with concurrency (5 concurrent threads, but heavy load) and creating a newWorkingMemory - there are hangs/lock issues with the weak hashmap that points from the Single rule base to the spawned working memories. This is not surprising, blah blah blah.... Anyway, one possible solution is to have a call where users who *want* to update an existing long lived working memory changes, pass in the WM to the rulebase, with say "refresh rules" - ie the methods like removeRule() on a rule base, require a working memory to be passed in. We can still keep the old WeakHashMap, just make it non default behaviour (it cannot scale the way it is now - with the default behaviour in my opinion). STACK trace follows: I'm using Java 1.5_09 on Linux. The app uses 5 simultaneous threads at the moment. They never share WorkingMemory instances but do share the same RuleBase. A thread dump (see below) shows all threads being stuck in java.util.WeakHashMap, which is called from AbstractRuleBase.addWorkingMemory. Has anyone seen this before? I attempted to synchronize the method that's the entry point to newWorkingMemory(). That definitely made the problem happen less often but didn't solve it completely. Anyone knows any other workarounds? Thanks, Per "CW4" prio=1 tid=0x1a4fd7a8 nid=0xc44 runnable [0x1a2fe000..0x1a2fefb0] at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:289) at java.util.WeakHashMap.getTable(WeakHashMap.java:297) at java.util.WeakHashMap.put(WeakHashMap.java:394) at org.drools.common.AbstractRuleBase.addWorkingMemory(Unknown Source) at org.drools.reteoo.ReteooRuleBase.newWorkingMemory(Unknown Source) at org.drools.common.AbstractRuleBase.newWorkingMemory(Unknown Source) "CW3" prio=1 tid=0x1a4fd5f0 nid=0xc43 runnable [0x1a6fe000..0x1a6fee30] at java.util.WeakHashMap.put(WeakHashMap.java:397) at org.drools.common.AbstractRuleBase.addWorkingMemory(Unknown Source) at org.drools.reteoo.ReteooRuleBase.newWorkingMemory(Unknown Source) at org.drools.common.AbstractRuleBase.newWorkingMemory(Unknown Source) "CW2" prio=1 tid=0x1a4fd100 nid=0xc42 runnable [0x1a8e5000..0x1a8e5eb0] at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:289) at java.util.WeakHashMap.getTable(WeakHashMap.java:297) at java.util.WeakHashMap.put(WeakHashMap.java:394) at org.drools.common.AbstractRuleBase.addWorkingMemory(Unknown Source) at org.drools.reteoo.ReteooRuleBase.newWorkingMemory(Unknown Source) at org.drools.common.AbstractRuleBase.newWorkingMemory(Unknown Source) "CW1" prio=1 tid=0x19afca78 nid=0xc41 runnable [0x1a966000..0x1a967130] at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:289) at java.util.WeakHashMap.getTable(WeakHashMap.java:297) at java.util.WeakHashMap.put(WeakHashMap.java:394) at org.drools.common.AbstractRuleBase.addWorkingMemory(Unknown Source) at org.drools.reteoo.ReteooRuleBase.newWorkingMemory(Unknown Source) at org.drools.common.AbstractRuleBase.newWorkingMemory(Unknown Source) at "CW0" prio=1 tid=0x19afc7d8 nid=0xc40 runnable [0x1aafe000..0x1aaff1b0] at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:289) at java.util.WeakHashMap.getTable(WeakHashMap.java:297) at java.util.WeakHashMap.put(WeakHashMap.java:394) at org.drools.common.AbstractRuleBase.addWorkingMemory(Unknown Source) at org.drools.reteoo.ReteooRuleBase.newWorkingMemory(Unknown Source) at org.drools.common.AbstractRuleBase.newWorkingMemory(Unknown Source) at -- 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, 3 months

6
9
0 / 0

[JBoss JIRA] Created: (JBAS-4348) SecurityDeployer:JaccPolicyBean starts after components in the deployment have started

by Anil Saldhana (JIRA)

SecurityDeployer:JaccPolicyBean starts after components in the deployment have started -------------------------------------------------------------------------------------- Key: JBAS-4348 URL: http://jira.jboss.com/jira/browse/JBAS-4348 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-5.0.0.Beta2 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: JBossAS-5.0.0.Beta3 The JaccPolicy bean for the top level deployment should add dependencies on the individual components in the deployment, such that once they are started, it can start thereby commit the policy configuration. Refer to the discussion in the forum thread 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

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBAS-3071) MemoryLeak (redeployment) on EJB3

by Clebert Suconic (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3071?page=all ] Clebert Suconic closed JBAS-3071. --------------------------------- > MemoryLeak (redeployment) on EJB3 > --------------------------------- > > Key: JBAS-3071 > URL: http://jira.jboss.com/jira/browse/JBAS-3071 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB3 > Affects Versions: JBossAS-4.0.4.CR2 > Reporter: Clebert Suconic > Assigned To: Carlo de Wolf > Priority: Critical > Fix For: JBossAS-4.2.0.CR2, JBossAS-5.0.0.Beta2 > > Attachments: leaks.txt > > > This might be caused by JBAS-3016: > But I'm seeing this strong reference: > org.jboss.mx.loading.UnifiedClassLoader3@33411906 > !--- org.jboss.ejb3.stateless.StatelessContainer@29610827 > We should make sure EJB3 packages are not leaking. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4346) Upgrade jboss remoting to 2.2.0.GA

by Dimitris Andreadis (JIRA)

Upgrade jboss remoting to 2.2.0.GA ---------------------------------- Key: JBAS-4346 URL: http://jira.jboss.com/jira/browse/JBAS-4346 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Remoting Affects Versions: JBossAS-4.2.0.CR2 Reporter: Dimitris Andreadis Assigned To: Tom Elrod Fix For: JBossAS-4.2.0.GA Create an issue to track if the upgrade works. -- 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, 3 months

1
5
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 April 2007