November 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-536) FunctionResolver is screwed for primitives

by Mark Proctor (JIRA)

FunctionResolver is screwed for primitives --------------------------------------------- Key: JBRULES-536 URL: http://jira.jboss.com/jira/browse/JBRULES-536 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m1 Function resolver is not correctly using primitives. -- 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, 6 months

2
4
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1076) User registration with email verification does not work

by Jean-Fran￧ois El Fouly (JIRA)

User registration with email verification does not work ------------------------------------------------------- Key: JBPORTAL-1076 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1076 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.4 Final Environment: Development PC / Windows XP Reporter: Jean-Fran￧ois El Fouly Assigned To: Julien Viet In portal-core.war/WEB-INF/portlet.xml I changed the subscriptionMode parameter from automatic to emailVerification (I have the feeling it worked in JBoss Portal 2.0 but I may be wrong). I tested the functionality and got an error 500 page with a stack trace: 2006-10-08 20:19:42,656 ERROR [org.jboss.portal.core.portlet.user.UserPortlet] The portlet threw an exception java.lang.NullPointerException at org.jboss.portal.core.portlet.user.UserPortlet.generateValidationEmail(UserPortlet.java:936) at org.jboss.portal.core.portlet.user.UserPortlet.userRegister(UserPortlet.java:624) I had a look at the code at this place. There is a TODO that makes me think it is not meant to work in this version. Can someone confirm ? I'll revert to automatic subscription but... I don't like that too much. -- 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, 6 months

2
2
0 / 0

[JBoss JIRA] Commented: (JBCACHE-595) Merge API interfaces

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-595?page=comments#action_12346512 ] Manik Surtani commented on JBCACHE-595: --------------------------------------- Cool. One other small thing: for completeness the MapModifications struct should probably also have a "public Map unmodifiedEntries" field. Manik Surtani wrote: Ok, sounds cool, will add this to the JIRA task. How about a variation on Ben's idea of providing an enum to specify the type of change? Sample API follows. /** * Called before and after a {@link Node} is modified. Data passed in the * <code>modData</code> param can be used to determine what was modified. * * When called with <code>pre == true</code>, <code>modData</code> is the * initial state of the {@link Node} before modification. * * When called with <code>pre == false</code>, the contents of <code>modData</code> * depend on the value of <code>modTtype</code>: * <ul> * <li>PUT_KEY_VALUE: Map contains the single key/value pair that was added.</li> * <li>REMOVE_KEY_VALUE: Map contains the single key/value pair that was removed.</li> * <li>PUT_MAP: Map contains the new state of the {@link Node} following modification. * This map includes modified key/value pairs as well as any that were not affected.</li> * </ul> * * Implementations interested in seeing the difference in the node data in the PUT_MAP case * can cache the <code>modData</code> map passed when <code>pre == true</code>, and then * when the <code>pre == false</code> callback is received, pass the cached map and the new * <code>modData</code> to {@link org.jboss.cache.util.Util.diffNodeData(Map pre, Map post)}. * * @param fqn Fqn of the node being modified * @param pre <code>true</code> if the modification is about to be applied, * <code>false</code> if it has already been applied * @param isLocal <code>true</code> if the modification originated locally, * <code>false</code> if it was replicated from another node * @param modType PUT_KEY_VALUE, REMOVE_KEY_VALUE or PUT_MAP * @param modData Unmodifiable {@link Map}; will not be <code>null</code>. See * description above. */ public void nodeModified(Fqn fqn, boolean pre, boolean isLocal, ModificationType modType, Map modData); public class Util { public static MapModifications diffNodeData(Map pre, Map post) { // do the diff here } public static class MapModifications { public Map addedEntries; public Map removedEntries; public Map modifiedEntries; } } Advantage here is JBC goes to little effort to support this, so overhead is low if the listener isn't interested. CacheListener impls that are interested in modifications, but where the app never calls put(Fqn, Map) also have very little overhead. I believe Jerry's DistributedState is such a case. The big overhead of doing the diff is only incurred by CacheListener impls that care, and we provide much of the code to do it for them. > Merge API interfaces > -------------------- > > Key: JBCACHE-595 > URL: http://jira.jboss.com/jira/browse/JBCACHE-595 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.SP1 > Reporter: Manik Surtani > Assigned To: Manik Surtani > Priority: Blocker > Fix For: 2.0.0.GA > > Time Spent: 30 minutes > Remaining Estimate: 0 minutes > > * Merge TreeCacheListener, EnhancedTreeCacheListener, add an API to pass in data > * Merge CacheLoader + ExtendedCacheLoader -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1102) In Mgmt portlet, unable to set Renderers for a Window (pull-downs disabled) and other pulldowns enabled, but should be disabled

by Ian White (JIRA)

In Mgmt portlet, unable to set Renderers for a Window (pull-downs disabled) and other pulldowns enabled, but should be disabled ------------------------------------------------------------------------------------------------------------------------------- Key: JBPORTAL-1102 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1102 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.6.DR1 Environment: Server 4.0.5.GA XP Reporter: Ian White In the management portlet. Expand a portal in the tree. Select a Window. Seems to be that the disabling / enabling of the puilldowns under the Themes section is wrong. -- 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, 6 months

1
1
0 / 0

[JBoss JIRA] Commented: (JBCACHE-388) Provide modified data in callbacks

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-388?page=comments#action_12346494 ] Manik Surtani commented on JBCACHE-388: --------------------------------------- See JBCACHE-595 > Provide modified data in callbacks > ---------------------------------- > > Key: JBCACHE-388 > URL: http://jira.jboss.com/jira/browse/JBCACHE-388 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.2.4SP1, 1.2.4, 1.2.4beta, 1.2.3, 1.2.2, 1.2.1, 1.2 > Reporter: Bela Ban > Assigned To: Manik Surtani > Fix For: 2.0.0.GA > > > All callbacks should ship the data they refer to, e.g. put() should have a list of modified / inserted attributes etc. > We should define the data that needs to e provided for each callback. > This should go into ExtendedTreeCacheListener (which will be merged with TreeCacheListener in 2.x). -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBCACHE-595) Merge API interfaces

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-595?page=comments#action_12346495 ] Manik Surtani commented on JBCACHE-595: --------------------------------------- See JBCACHE-388 > Merge API interfaces > -------------------- > > Key: JBCACHE-595 > URL: http://jira.jboss.com/jira/browse/JBCACHE-595 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.SP1 > Reporter: Manik Surtani > Assigned To: Manik Surtani > Priority: Blocker > Fix For: 2.0.0.GA > > Time Spent: 30 minutes > Remaining Estimate: 0 minutes > > * Merge TreeCacheListener, EnhancedTreeCacheListener, add an API to pass in data > * Merge CacheLoader + ExtendedCacheLoader -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBCACHE-595) Merge API interfaces

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-595?page=all ] Manik Surtani reopened JBCACHE-595: ----------------------------------- Reopened to add an Enum to nodeModified() event so it identifies whether data has been added, removed or modified. Data map passed in would only contain data added, removed or modified. > Merge API interfaces > -------------------- > > Key: JBCACHE-595 > URL: http://jira.jboss.com/jira/browse/JBCACHE-595 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.SP1 > Reporter: Manik Surtani > Assigned To: Manik Surtani > Priority: Blocker > Fix For: 2.0.0.GA > > Time Spent: 30 minutes > Remaining Estimate: 0 minutes > > * Merge TreeCacheListener, EnhancedTreeCacheListener, add an API to pass in data > * Merge CacheLoader + ExtendedCacheLoader -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-619) PojoCache to support JDK5.0 Enum

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-619?page=all ] Ben Wang resolved JBCACHE-619. ------------------------------ Resolution: Done > PojoCache to support JDK5.0 Enum > -------------------------------- > > Key: JBCACHE-619 > URL: http://jira.jboss.com/jira/browse/JBCACHE-619 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: 2.0.0.GA > > Original Estimate: 4 days > Remaining Estimate: 4 days > > In JDK5.0, Enum is Serializabe. We need to look into whether it is possible to intercept Enum operation as well. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBCACHE-619) PojoCache to support JDK5.0 Enum

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-619?page=comments#action_12346491 ] Ben Wang commented on JBCACHE-619: ---------------------------------- Currently there is a test case: o.j.c.pojo.EnumTest for that. > PojoCache to support JDK5.0 Enum > -------------------------------- > > Key: JBCACHE-619 > URL: http://jira.jboss.com/jira/browse/JBCACHE-619 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: 2.0.0.GA > > Original Estimate: 4 days > Remaining Estimate: 4 days > > In JDK5.0, Enum is Serializabe. We need to look into whether it is possible to intercept Enum operation as well. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBCACHE-619) PojoCache to support JDK5.0 Enum

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-619?page=comments#action_12346490 ] Ben Wang commented on JBCACHE-619: ---------------------------------- Two issues need to be resolved: 1. java.lang.Enum, of which is an abstract class, has two final fields: name and ordinal. The name field will need to be replicated by any sub-class in PojoCache. In addition, it hasn't had a no-arg constructor. So during failover, we will need to contruct the Enum instance from: Enum.valueOf(class, name). As a result, name is needed for replication. 2. In order to replicate name field, we will need to add a flag to allow that. This can be done via aop interceptor stack. See JBCACHE-839. > PojoCache to support JDK5.0 Enum > -------------------------------- > > Key: JBCACHE-619 > URL: http://jira.jboss.com/jira/browse/JBCACHE-619 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: 2.0.0.GA > > Original Estimate: 4 days > Remaining Estimate: 4 days > > In JDK5.0, Enum is Serializabe. We need to look into whether it is possible to intercept Enum operation as well. -- 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, 6 months

1
0
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 November 2006