August 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Resolved: (JBCACHE-663) Setup system property for Id string separator

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-663?page=all ] Jason T. Greene resolved JBCACHE-663. ------------------------------------- Fix Version/s: (was: PojoCache) Resolution: Rejected > Setup system property for Id string separator > --------------------------------------------- > > Key: JBCACHE-663 > URL: http://jira.jboss.com/jira/browse/JBCACHE-663 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > In 2.0 release, we will use id String instead the old fqn. We will also use a system property called jbosscache.separator to allow user to use a different character as the separator. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-165) Option to exclude fields from "aspectized" in aop

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-165?page=all ] Jason T. Greene closed JBCACHE-165. ----------------------------------- Fix Version/s: (was: 2.1.0.GA) Resolution: Out of Date See @Transient > Option to exclude fields from "aspectized" in aop > ------------------------------------------------- > > Key: JBCACHE-165 > URL: http://jira.jboss.com/jira/browse/JBCACHE-165 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Priority: Minor > Original Estimate: 2 days > Remaining Estimate: 2 days > > There may a time when a user wants certain fields in the POJO to be excluded from TreeCacheAop management. Currently, if a field is declared "transient", we have that effect. But still we may want to have a flag for this specific purpose. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBCACHE-318) CacheLoader persistent item should have an age limit

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-318?page=all ] Jason T. Greene reassigned JBCACHE-318: --------------------------------------- Assignee: Manik Surtani (was: Jason T. Greene) > CacheLoader persistent item should have an age limit > ---------------------------------------------------- > > Key: JBCACHE-318 > URL: http://jira.jboss.com/jira/browse/JBCACHE-318 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Manik Surtani > Fix For: 2.1.0.GA > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > Currently items that are persisted has no notion of age out. So let's say it is fairly common in SFSB to have the state not live more than 2 weeks in the store, for example. The other usage is when the cache crashed and the persistent store won't get cleaned up even when the items are orphaned. > Bela refused to put this functionality in the cache loader layer. So Manik's idea is to wrap around the object in the CacheStoreInterceptor with an additional timestamp. This way an offline thread can come in and clean them. > We can also check how does the current SFSB does this? -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-281) PojoCahce initialize "aspectized" pojos when first retrieved

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-281?page=all ] Jason T. Greene resolved JBCACHE-281. ------------------------------------- Fix Version/s: (was: PojoCache 2.1.0) Resolution: Out of Date This is already done in detach() > PojoCahce initialize "aspectized" pojos when first retrieved > ------------------------------------------------------------ > > Key: JBCACHE-281 > URL: http://jira.jboss.com/jira/browse/JBCACHE-281 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Original Estimate: 3 days > Remaining Estimate: 3 days > > Currently, when we do getObject for the first time, we don't initialize the "aspectized" pojo after a get/set is requested. As a result, some of the fields will be un-initialized untill after they are accessed. > We need to provide an option to actively initialize the pojos. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-71) Resizing cache at runtime

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-71?page=all ] Jason T. Greene closed JBCACHE-71. ---------------------------------- Fix Version/s: (was: 3.0.0) Resolution: Out of Date There is a new region design. > Resizing cache at runtime > ------------------------- > > Key: JBCACHE-71 > URL: http://jira.jboss.com/jira/browse/JBCACHE-71 > Project: JBoss Cache > Issue Type: Sub-task > Reporter: Ben Wang > Assigned To: Jason T. Greene > Original Estimate: 3 days > Remaining Estimate: 3 days > > With the dynamic runtime configuration of eviction policy, we should be able to resize the cache at 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

18 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-1039) OutOfMemoryError While using multi h:selectOneRaido in dataform with multy columns

by zhou guangzhao (JIRA)

OutOfMemoryError While using multi h:selectOneRaido in dataform with multy columns ---------------------------------------------------------------------------------- Key: JBPM-1039 URL: http://jira.jboss.com/jira/browse/JBPM-1039 Project: JBoss jBPM Issue Type: Bug Components: Web Interface Affects Versions: jBPM jPDL 3.2.1 Environment: jBPM 3.2.1 Tomcat 6.0.14 Reporter: zhou guangzhao Assigned To: Tom Baeyens The following taskform code works in JBPM3.2.GA. But when running in JBPM 3.2.1, it causes OutOfMemoryError. By testing, I found that if I change <jbpm:dataform columns="2"> to <jbpm:dataform>, it will work well in both JBPM3.2.GA and JBPM3.2.1. Sometimes it maybe works in JBPM3.2.1. But while adding more h:selectOneRadio, I get the error. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >  <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:c="http://java.sun.com/jstl/core" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" xmlns:tf="http://jbpm.org/jsf/tf" xmlns:jbpm="http://jbpm.org/jsf"> <ui:component> <jbpm:dataform columns="2"> <f:facet name="header"> <h:outputText value="#{taskName}"/> </f:facet>  <jbpm:datacell> <f:facet name="header"> <h:outputText value="Sex"/> </f:facet> <h:selectOneRadio id="StudentSex" value="#{var['StudentSex']}"> <f:selectItem itemLabel="Male" itemValue="Male"/> <f:selectItem itemLabel="Female" itemValue="Female"/> </h:selectOneRadio> </jbpm:datacell> <jbpm:datacell> <f:facet name="header"> <h:outputText value="HasAS"/> </f:facet> <h:selectOneRadio id="HasAS" value="#{var['HasAS']}" > <f:selectItem itemLabel="Yes" itemValue="Yes"/> <f:selectItem itemLabel="No" itemValue="No"/> </h:selectOneRadio> </jbpm:datacell> <jbpm:datacell> <f:facet name="header"> <h:outputText value="Actions"/> </f:facet>  <tf:saveButton value="Save"/> <tf:cancelButton value="Cancel"/> <tf:transitionButton value="Save and Close"/> </jbpm:datacell> </jbpm:dataform> </ui:component> </html> -- 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, 11 months

2
1
0 / 0

[JBoss JIRA] Closed: (JBCACHE-288) Enable garbage collection for Pojo under cache management

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-288?page=all ] Jason T. Greene closed JBCACHE-288. ----------------------------------- Fix Version/s: (was: PojoCache) Resolution: Rejected > Enable garbage collection for Pojo under cache management > --------------------------------------------------------- > > Key: JBCACHE-288 > URL: http://jira.jboss.com/jira/browse/JBCACHE-288 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Original Estimate: 1 week > Remaining Estimate: 1 week > > Currently, once the pojo is put into cache, it won't get gced unless user specifically issues removeObject. There is eviction policy. However, it is coupled with cache loader so the object is still around for a specific time span. We should come up with a way to gc these pojos properly. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-518) Investigate use a new replication schema for PojoCache

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-518?page=all ] Jason T. Greene updated JBCACHE-518: ------------------------------------ Fix Version/s: (was: PojoCache 2.2.0) > Investigate use a new replication schema for PojoCache > ------------------------------------------------------ > > Key: JBCACHE-518 > URL: http://jira.jboss.com/jira/browse/JBCACHE-518 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > We should look into a new replication schema for PojoCache putObject and removeObject operation. Idea is during replication, instead of breaking it down and do lots of puts, we replicate the original objects and map it into PojoCache on the other side. This has potential of saving the binary size but has pontential to be more cpu intensive. > The other issue is what to do with automicity during putObject and removeObject? -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-518) Investigate use a new replication schema for PojoCache

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-518?page=all ] Jason T. Greene resolved JBCACHE-518. ------------------------------------- Resolution: Rejected > Investigate use a new replication schema for PojoCache > ------------------------------------------------------ > > Key: JBCACHE-518 > URL: http://jira.jboss.com/jira/browse/JBCACHE-518 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: PojoCache 2.2.0 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > We should look into a new replication schema for PojoCache putObject and removeObject operation. Idea is during replication, instead of breaking it down and do lots of puts, we replicate the original objects and map it into PojoCache on the other side. This has potential of saving the binary size but has pontential to be more cpu intensive. > The other issue is what to do with automicity during putObject and removeObject? -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1325) ConsumerCacheInterceptor : should not use the cache just after login

by Antoine Herzog (JIRA)

ConsumerCacheInterceptor : should not use the cache just after login -------------------------------------------------------------------- Key: JBPORTAL-1325 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1325 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal Core Environment: jbp 2.4.0 Reporter: Antoine Herzog Assigned To: Julien Viet Use case : - user come to the site. - Portlet show views for unchecked user. These views are put in the cache. - user log in, let's say as admin - the cached views still show the previous things, not taking into account the change of authorizations - the user can't see the proper things usual needs : - for I18n portals : change of locale when user log in. all the portlets must do the change, not depending on cache - for admin or special roles features in the portlet views - for modes depending on roles (see forum post) In the default portal, there are no use of cache. so all these use cases are fullfiled. to reproduce the problem : - put some cache on the user portlet (great feature for prod), the user portlet window may not update after logging. resolution : in the ConsumerCacheInterceptor the CacheKey do not take into account the login state. see : public CacheKey(StateString navigationalState, WindowState windowState, Mode mode) so store the user name (or "unchecked") in the CacheEntry. put the parameter "userOfFragment" in the CacheKey. when retrieving the CacheEntry, compare the currentUser and the userOfFragment, and don't use the cache if different. just to see : can we have access to the logued user in this interceptor ? (that, i don't know) -- 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, 11 months

3
10
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 August 2007