[jira] Updated: (JCR-719) XPath parser ignores parent axis
[ https://issues.apache.org/jira/browse/JCR-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-719: -- Fix Version/s: 1.3 Issue Type: New Feature (was: Bug) Affects Version/s: (was: 1.1.1) (was: 1.1) (was: 1.0.1) (was: 1.0) (was: 0.9) (was: 1.2.1) XPath parser ignores parent axis Key: JCR-719 URL: https://issues.apache.org/jira/browse/JCR-719 Project: Jackrabbit Issue Type: New Feature Components: xpath Reporter: Marcel Reutegger Assigned To: Marcel Reutegger Priority: Minor Fix For: 1.3 The query handler in Jackrabbit does not support the parent axis and should throw an invalid query exception in that case. Example query: //foo/.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-713) ConcurrentModificationException during registration of nodetypes
[
https://issues.apache.org/jira/browse/JCR-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-713:
--
Affects Version/s: 1.2.1
ConcurrentModificationException during registration of nodetypes
Key: JCR-713
URL: https://issues.apache.org/jira/browse/JCR-713
Project: Jackrabbit
Issue Type: Bug
Components: core
Affects Versions: 1.1.1, 1.2.1
Reporter: Martijn Hendriks
Assigned To: Stefan Guggisberg
Fix For: 1.2.2
During the registration of a set of nodetypes this exception may be
encountered:
java.util.ConcurrentModificationException
at
org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.checkMod(AbstractReferenceMap.java:761)
at
org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.hasNext(AbstractReferenceMap.java:735)
at
org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.notifyRegistered(NodeTypeRegistry.java:1750)
at
org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.registerNodeTypes(NodeTypeRegistry.java:223)
It seems that the copying of the listeners triggered this exception:
private void notifyRegistered(QName ntName) {
// copy listeners to array to avoid ConcurrentModificationException
NodeTypeRegistryListener[] la =
new NodeTypeRegistryListener[listeners.size()];
Iterator iter = listeners.values().iterator();
int cnt = 0;
1750: while (iter.hasNext()) {
la[cnt++] = (NodeTypeRegistryListener) iter.next();
}
for (int i = 0; i la.length; i++) {
if (la[i] != null) {
la[i].nodeTypeRegistered(ntName);
}
}
}
The methods notifyReRegistered and notifyUnregistered will probably
suffer from the same problem.
Reproduction of this exception may be tricky; it only occurred once in our
application. It is probably a race condition: another thread might access the
listeners during the copy. It may be helpful to use a debugger and set a
breakpoint in the middle of the copy giving other threads the opportunity to
access the listeners...
We think that a possible solution is the following:
/**
* Notify the listeners that a node type codentName/code has been
registered.
*/
private void notifyRegistered(QName ntName) {
// copy listeners to array to avoid ConcurrentModificationException
NodeTypeRegistryListener[] la;
synchronized (listeners) {
la = (NodeTypeRegistryListener[]) listeners.values().toArray(new
NodeTypeRegistryListener[listeners.size()]);
}
for (int i = 0; i la.length; i++) {
if (la[i] != null) {
la[i].nodeTypeRegistered(ntName);
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCR-549) TransientFileFactory may throw ConcurrentModificationException on shutdown
[ https://issues.apache.org/jira/browse/JCR-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting closed JCR-549. - TransientFileFactory may throw ConcurrentModificationException on shutdown -- Key: JCR-549 URL: https://issues.apache.org/jira/browse/JCR-549 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 0.9, 1.0, 1.0.1 Environment: svn: 437594 Reporter: Marcel Reutegger Assigned To: Stefan Guggisberg Priority: Minor When Jackrabbit is stopped the shutdown hook of the TransientFileFactory iterates over all tracked temp files and deletes them. At the same time the reaper thread may still remove file references from the list of tracked temp files. This may lead to a ConcurrentModificationException in the shutdown hook: java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(Unknown Source) at java.util.AbstractList$Itr.next(Unknown Source) at org.apache.jackrabbit.util.TransientFileFactory$1.run(TransientFileFactory.java:86) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCR-543) DocViewSAXEventGenerator produces invalid SAX stream
[
https://issues.apache.org/jira/browse/JCR-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting closed JCR-543.
-
DocViewSAXEventGenerator produces invalid SAX stream
Key: JCR-543
URL: https://issues.apache.org/jira/browse/JCR-543
Project: Jackrabbit
Issue Type: Bug
Components: xml
Affects Versions: 1.0.1
Reporter: Jaka Jaksic
Assigned To: Stefan Guggisberg
ISO9075.encode() is called twice in DocViewSAXEventGenerator.leaving(), which
produces invalid endElement events.
Faulty block of code (note the encode method called twice):
// encode node name to make sure it's a valid xml name
name = ISO9075.encode(name);
// element name
String elemName;
if (node.getDepth() == 0) {
// root node needs a name
elemName = jcrRoot;
} else {
// encode node name to make sure it's a valid xml name
elemName = ISO9075.encode(name);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCR-339) null pointer when cloning to different workspace under the root node
[
https://issues.apache.org/jira/browse/JCR-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting closed JCR-339.
-
null pointer when cloning to different workspace under the root node
Key: JCR-339
URL: https://issues.apache.org/jira/browse/JCR-339
Project: Jackrabbit
Issue Type: Bug
Components: core
Environment: Microsoft Windows 2000, Service pack 4
Reporter: Giota Karadimitriou
Assigned To: Stefan Guggisberg
Attachments: BatchedItemOperations.java
I have been testing my application with jackrabbit 1.0 and found a small
error which causes a null pointer exception.
Class org.apache.jackrabbit.core.BatchedItemOperations
public void checkAddNode(...
//line 576
// make sure parent node is not protected
if (parentDef.isProtected()) {
if (parentDef!=null parentDef.isProtected()) { //proposed solution
The code that tested that is this below .
One must have 2 workspaces to run this and try to clone a node of the first
workspace under the root of the second:
String originalWorkspace = entry.getWorkspace();
String originalPath = entry.getAbsolutePath();
Session originalSession = getSession(originalWorkspace);
Session session = getSession(secondWorkspace);
log.debug(originalSession= + originalSession);
Node rnOriginal=originalSession.getRootNode();
Node node=rnOriginal.getNode(originalPath.substring(1));
log.debug(node= + node);
log.debug(session= + session);
Workspace ws = session.getWorkspace();
log.debug(ws= + ws.getName());
String name=Util.getName(originalPath); //gets just the file name
log.debug(name= + name);
ws.clone(originalWorkspace, originalPath,
Constants.PATH_SEPARATOR_CHAR + name, true);
Node rn = session.getRootNode();
log.debug(rn= + rn);
Node movedNode = rn.getNode(name);
log.debug(movedNode= + movedNode);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-718) NoSuchItemStateException on removing node (no versioning)
[
https://issues.apache.org/jira/browse/JCR-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-718:
--
Component/s: core
NoSuchItemStateException on removing node (no versioning)
-
Key: JCR-718
URL: https://issues.apache.org/jira/browse/JCR-718
Project: Jackrabbit
Issue Type: Bug
Components: core
Affects Versions: 1.2.1
Reporter: Massimiliano Cuccia
I'm using jackrabbit 1.2.1
with no versioning
with a very simple SimpleAccessManager (this try to compute the path of the
passed ItemId and verify permissions over that path)
when I remove a node (nt:file or nt:folder), calling session.save() I
obtains the exception reported below.
is it really a bug or am i wrong?
thanks
the following is the code I'm using to build the path
- CODE START
public String getStringPath(ItemId id) throws ItemNotFoundException,
RepositoryException, NoPrefixDeclaredException
{
String p = ;
NamespaceResolver nsResolver = ((HierarchyManagerImpl)
hierMgr).getNamespaceResolver();
Path path = hierMgr.getPath(id);
PathElement[] pe = path.getElements();
for (int i = 0; i pe.length; i++)
{
if (pe[i].denotesName())
p += / + pe[i].toJCRName(nsResolver);
}
return p;
}
- CODE END
- START
javax.jcr.ItemNotFoundException: failed to build path of
d688e92f-26ae-4f7c-aba7-aaff1df62c2c: d688e92f-26ae-4f7c-aba7-aaff1df62c2c:
d688e92f-26ae-4f7c-aba7-aaff1df62c2c
at
org.apache.jackrabbit.core.HierarchyManagerImpl.getPath(HierarchyManagerImpl.java:362)
at
org.apache.jackrabbit.core.CachingHierarchyManager.getPath(CachingHierarchyManager.java:224)
at
it.unict.faq.jackrabbit.SimpleAccessManager.getStringPath(SimpleAccessManager.java:238)
at
it.unict.faq.jackrabbit.SimpleAccessManager.controllo(SimpleAccessManager.java:215)
at
it.unict.faq.jackrabbit.SimpleAccessManager.isGranted(SimpleAccessManager.java:183)
at
org.apache.jackrabbit.core.ItemImpl.validateTransientItems(ItemImpl.java:645)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1162)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:821)
at
it.unict.faq.driver.manager.impl.DAO.JcrDAO.CancellaNodo(JcrDAO.java:638)
at
it.unict.faq.driver.manager.impl.DocumentServerManager.ds_del(DocumentServerManager.java:58)
at elearn.portal.action.ds_del_portal.execute(ds_del_portal.java:28)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:421)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:226)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1158)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
at
org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
at
org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
org.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:81)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at
[jira] Updated: (JCR-721) Duplicate key in DatabasePersistenceManager
[
https://issues.apache.org/jira/browse/JCR-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-721:
--
Component/s: core
Affects Version/s: 1.2.1
Summary: Duplicate key in DatabasePersistenceManager (was:
DatabasePersistenceManager: store failed)
You're right, this seems like a concurrency issue.
Duplicate key in DatabasePersistenceManager
---
Key: JCR-721
URL: https://issues.apache.org/jira/browse/JCR-721
Project: Jackrabbit
Issue Type: Bug
Components: core
Affects Versions: 1.2.1
Environment: JackRabbit 1.2.1 using the default Derby repository.xml.
Reporter: Martijn Hendriks
Hi,
I ran into the exception pasted below. We had 2 threads that both were
saving. Maybe it is a race condition?
Regards,
Martijn Hendriks
GX creative online development B.V.
t: 024 - 3888 261
f: 024 - 3888 621
e: [EMAIL PROTECTED]
Wijchenseweg 111
6538 SW Nijmegen
http://www.gx.nl/
Jan 26, 2007 2:23:36 PM
org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager store
SEVERE: failed to write property state:
e3847bad-f1ee-4adb-a109-e134900935b7/{http://gx.nl}edit_language
ERROR 23505: The statement was aborted because it would have caused a
duplicate key value in a unique or primary key constraint or unique in dex
identified by 'DEFAULT_PROP_IDX' defined on 'DEFAULT_PROP'.
at org.apache.derby.iapi.error.StandardException.newException(Unknown
Source)
at
org.apache.derby.impl.sql.execute.IndexChanger.insertAndCheckDups(Unknown
Source)
at org.apache.derby.impl.sql.execute.IndexChanger.doInsert(Unknown
Source)
at org.apache.derby.impl.sql.execute.IndexChanger.insert(Unknown
Source)
at org.apache.derby.impl.sql.execute.IndexSetChanger.insert(Unknown
Source)
at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(Unknown
Source)
at
org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown
Source)
at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown
Source)
at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
Source)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown
Source)
at
org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.executeStmt(DatabasePersistenceManager.java:835)
at
org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:466)
at
org.apache.jackrabbit.core.persistence.AbstractPersistenceManager.store(AbstractPersistenceManager.java:75)
at
org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:274)
at
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:675)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:808)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326)
at
org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:302)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:295)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1210)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Apache Jackrabbit 1.2.2 release plan
Hi, On 1/19/07, Jukka Zitting [EMAIL PROTECTED] wrote: There are a few clustering improvements and some minor bugs already reported and fixed against the 1.2.1 release that is currently being voted on. Instead of further delaying the main release I am planning to create a 1.2.2 patch release in a few weeks after the main release gets published. I've updated the 1.2 branch with the issues currently targeted for 1.2.2. Let me know if there are some other issues you'd like to see fixed in this patch release. The current list of issues targeted for 1.2.2 is: New features * [JCR-702] - Allow database as backend for clustering Improvements * [JCR-703] - Add signature and major/minor version to the journal ... Bug fixes * [JCR-708] - SearchManager might throw when handling cluster event * [JCR-710] - NullPointerException in DatabasePersistenceManager and ... * [JCR-711] - Select * does not return declared properties of node ... * [JCR-712] - NPE Exception Thrown By FileJournal During Commit Operation * [JCR-713] - ConcurrentModificationException during registration of ... * [JCR-715] - Missing jackrabbit-rmi-service.xml from ... BR, Jukka Zitting
[jira] Created: (JCR-722) typo in the mimetypes.properties file
typo in the mimetypes.properties file - Key: JCR-722 URL: https://issues.apache.org/jira/browse/JCR-722 Project: Jackrabbit Issue Type: Bug Components: webdav Affects Versions: 1.2.1 Reporter: Glaucio Scheibel The Powerpoint mime-type (ppt) is wrong in mimetypes.properties file. It was written with a equals(=) caracter in place of a dot (.). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-723) OpenDocument files missing in mimetypes.properties
OpenDocument files missing in mimetypes.properties -- Key: JCR-723 URL: https://issues.apache.org/jira/browse/JCR-723 Project: Jackrabbit Issue Type: Improvement Components: webdav Affects Versions: 1.2.1 Reporter: Glaucio Scheibel Priority: Critical The mime-types from Oasis OpenDocument are missing from mimetypes.properties file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-723) OpenDocument files missing in mimetypes.properties
[ https://issues.apache.org/jira/browse/JCR-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469115 ] angela commented on JCR-723: while adding the missing mimetypes would be a quick short-term solution (and no problem), i was rather thinking about a mechanism, that allows to extend (or modify) the mimetype-lookup using the configuration. - adjusting summary OpenDocument files missing in mimetypes.properties -- Key: JCR-723 URL: https://issues.apache.org/jira/browse/JCR-723 Project: Jackrabbit Issue Type: Improvement Components: webdav Affects Versions: 1.2.1 Reporter: Glaucio Scheibel Priority: Critical The mime-types from Oasis OpenDocument are missing from mimetypes.properties file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-722) typo in the mimetypes.properties file
[ https://issues.apache.org/jira/browse/JCR-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela reassigned JCR-722: -- Assignee: angela typo in the mimetypes.properties file - Key: JCR-722 URL: https://issues.apache.org/jira/browse/JCR-722 Project: Jackrabbit Issue Type: Bug Components: webdav Affects Versions: 1.2.1 Reporter: Glaucio Scheibel Assigned To: angela The Powerpoint mime-type (ppt) is wrong in mimetypes.properties file. It was written with a equals(=) caracter in place of a dot (.). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-724) PropertyReadMethodsTest.testIsSame leaks session
PropertyReadMethodsTest.testIsSame leaks session Key: JCR-724 URL: https://issues.apache.org/jira/browse/JCR-724 Project: Jackrabbit Issue Type: Bug Components: test Reporter: Julian Reschke Assigned To: Julian Reschke Priority: Trivial The test case obtains a second session but doesn't logout(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-724) PropertyReadMethodsTest.testIsSame leaks session
[ https://issues.apache.org/jira/browse/JCR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved JCR-724. Resolution: Fixed Fixed with revision 501921. PropertyReadMethodsTest.testIsSame leaks session Key: JCR-724 URL: https://issues.apache.org/jira/browse/JCR-724 Project: Jackrabbit Issue Type: Bug Components: test Reporter: Julian Reschke Assigned To: Julian Reschke Priority: Trivial The test case obtains a second session but doesn't logout(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
What is difference between repository index and workspace index
I just find the index size under repository directory is smaller than the workspace directory.Who can help me understand this.Thanks!
[jira] Created: (JCR-725) Configuration of CacheManager memory sizes
Configuration of CacheManager memory sizes -- Key: JCR-725 URL: https://issues.apache.org/jira/browse/JCR-725 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.2.1 Reporter: Jaka Jaksic Priority: Trivial (I already posted this as comments under JCR-619.) The maximum size for all caches in CacheManager is hardcoded to 16 megabytes and there's no way to change that. It would be nice if this as well as other CacheManager parameters were configurable. It's just a waste running Jackrabbit on a server with gigabytes of memory and only using 16 megabytes for cache... I have created a really simple and straightforward patch (jackrabbit-cachemanager-config.patch) which enables reaching the CacheManager instance through RepositoryImpl object and setting all three of its memory parameters. The memory parameters are no longer static constants, but instance fields getting initial values from constants (so the default behavior of the class remains the same). (It would be even nicer if these parameters were configurable via configuration files, but that should probably be implemented by someone close to the project.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-725) Configuration of CacheManager memory sizes
[ https://issues.apache.org/jira/browse/JCR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaka Jaksic updated JCR-725: Attachment: jackrabbit-cachemanager-config.patch Configuration of CacheManager memory sizes -- Key: JCR-725 URL: https://issues.apache.org/jira/browse/JCR-725 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.2.1 Reporter: Jaka Jaksic Priority: Trivial Attachments: jackrabbit-cachemanager-config.patch (I already posted this as comments under JCR-619.) The maximum size for all caches in CacheManager is hardcoded to 16 megabytes and there's no way to change that. It would be nice if this as well as other CacheManager parameters were configurable. It's just a waste running Jackrabbit on a server with gigabytes of memory and only using 16 megabytes for cache... I have created a really simple and straightforward patch (jackrabbit-cachemanager-config.patch) which enables reaching the CacheManager instance through RepositoryImpl object and setting all three of its memory parameters. The memory parameters are no longer static constants, but instance fields getting initial values from constants (so the default behavior of the class remains the same). (It would be even nicer if these parameters were configurable via configuration files, but that should probably be implemented by someone close to the project.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Apache Jackrabbit 1.2.2 release plan
Hi Jukka! I've updated the 1.2 branch with the issues currently targeted for 1.2.2. Let me know if there are some other issues you'd like to see fixed in this patch release. I've just created the issue JCR-725 (about making cache sizes in CacheManager configurable) and attached a proposed patch. Do you think it could be included in 1.2.2? The thing is that we have hundreds of workspaces with plenty of data and the cache easily took up several hundred megabytes before limiting the size in version 1.2. Now while limiting the size of caches is definitely a good idea, I would not like a constant upper limit to unnecessarily decrease the repository's performance. The patch is really trivial and by default changes nothing, so I don't think it could cause much trouble. Regards, Jaka
Session handling problem
Hi all, I am getting an intermittnet problem with jackrabbit sessions . Basically everything seems fine but every now and again when trying to acquire a session the system seems to lock up. Are there any known issues with either: 1) Sharing sessions using commons-pooling? 2) Doing workspace scoped operations (clone etc) while other people are performing session scoped operations like saving nodes? These will probably not both be affecting the same node (Although I can not confirm this but based on the workflow our users perform it should not be the case) ? Any help would be great. Thanks, Shane.
