Encoded/Decoded problem
Hello guys,
I am working with JCR, and found a little deficiency. Let me explain on example
- running this simple program causes an exception:
class test {
public static void main(String args[]) {
String encoded = ISO9075.encode($String);
ISO9075.decode(encoded);
}
}
exception is StringIndexOutOfBoundsException.
The problem isn't really in bad implementation, but in wrong use of
Matcher.appendReplacement() method. This function must have the dolar sign ($)
and backslash (\) escaped with backslash. But in current implementation all
characters are passed to this function unescaped, what causes mentioned
exception when decoded string has dollars or backslashes. Hope fixing this will
not be a big deal.
Best Regards
Szymon Kuzniak
P.S. this is my implementation of decode() method.
public static String decode(String name) {
// quick check
if (name.indexOf(_x) 0) {
// not encoded
return name;
}
StringBuffer decoded = new StringBuffer();
Matcher m = ENCODE_PATTERN.matcher(name);
while (m.find()) {
String sign = Character.toString((char)
Integer.parseInt(m.group().substring(2, 6), 16));
if ($.equals(sign) || \\.equals(sign)) {
sign = \\+ sign;
}
m.appendReplacement(decoded, sign);
}
m.appendTail(decoded);
return decoded.toString();
}
Bierz ile chcesz! Nawet 5 zł bez wizyty w banku.
Rata od 35 zł. Wniosek i decyzja przez telefon. Kliknij i sprawdź:
http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fh11.htmlsid=863
Re: Additional version metadata
Hi JavaJ, For each version of a node, I would like to attach additional metadata such as the uuid of the user who created the node, a user-friendly version number, user comments, etc. Has anyone tried to do something similar? I would recommend to populate the node with additional versioning specific properties before you check it in (maybe in a separate mixin describing your additional meta information). This should allow any structure of meta-data and also a very convenient query. regards, david
Re: Refactoring of the backupTool
Hi, On 9/4/06, Nicolas [EMAIL PROTECTED] wrote: I am following our IM chat where you explained me a few things I didn't understand at first. I will summarize it here on the ML. Thanks! - Actually between RestoreBatchedItemOperations and BatchedItemOperations, I only have deleted the recursively add 'auto-create' child nodes defined in node type part. This way, I only create node. This way we only create node and so don't check for protection (since a node to be created is not yet protected :p). I could add some composition to this, but only to this part seems overkill. I don't really see what I can do on this. What do you think? If it's just a single feature then adding a flag for enabling/disabling it could also solve the need. - NodeVersionHistoriesUpdatableStateManager and UpdatableStateItemManager. Actually, I created one new UISM because I couldn't understand how the EventStateCollectionFactory worked (I tried null and to instantiate one but it didn't work), therefore couldn't reuse the LocalItemStateManager. If someone can explain it to me, I might be able to delete this class. The ESCF is used for sending observation events. For example the VersionManagerImpl contains the escFactory instance that you should be able to use. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
Re: Improving the accessibility of the Jackrabbit core
I will put in my 2c since I did not see many replies to this post and I think addressing this question is very important for any open source project. i have not had much time to play with JR due to other work, so some of this might already be there. . Screenshots or easily downloadable sample app which actually does something with custom node types. the base war download is good, but how far could you go with it. Most open source applications have a contacts application or a phone book, or something similar. something that has a face, like a jsp to view whats in the repository would be great . the wiki has not been updated regularly, either the information is old or not many people go to it . the deployment models - creating a complete tomcat dist, which has the various deployment options running right out of the box would be nice. . a java example to add node types, for example for a phone book, which CRUDs the node types would be nice . maybe a page, which lists the possibilities of applications that could be built with JR will be useful for newbies. just my 2c. Thanks Dave Nicolas [EMAIL PROTECTED] wrote: Hi, I have got familiar with JR codebase in the last few months and follow is based on my experience in the backup tool. The community is really helpful when you need some help but in order to understand the basic concept you need to dig into the code and into the JCR spec. A general documentation might be a good idea: a user one where key concepts are explained (versioning, nodetypes, and so on). We can I think mostly copy/paste from the JCR to the Wiki. We also need I believe some documentations about JR 's internals: how a node is updated what is an ItemState. BR Nico my blog! http://www.deviant-abstraction.net !! - All-new Yahoo! Mail - Fire up a more powerful email and get things done faster.
Re: Additional version metadata
That's an interesting idea. I think I might do that. Thanks! David Nuescheler wrote: Hi JavaJ, For each version of a node, I would like to attach additional metadata such as the uuid of the user who created the node, a user-friendly version number, user comments, etc. Has anyone tried to do something similar? I would recommend to populate the node with additional versioning specific properties before you check it in (maybe in a separate mixin describing your additional meta information). This should allow any structure of meta-data and also a very convenient query. regards, david -- View this message in context: http://www.nabble.com/Additional-version-metadata-tf2218551.html#a6156679 Sent from the Jackrabbit - Dev forum at Nabble.com.
XSL transformation from XML to CND nodetype format
Hi, There's been a few mentions about writing an XSL transformation for converting node type definitions from the XML format to the more readable CND format. The equivalent functionality is already available in terms of the XML and CND reader and writer classes in Jackrabbit, but an XSL transformation is in many cases a more convenient tool. Attached is a simple implementation of this transformation. I just hacked it together for a moment's need, so it for example fails to properly quote strings and doesn't set up correct namespace mappings. I'm posting it hoping that someone perhaps finds it useful or that it could eventually evolve to a point where we could use it to avoid the duplicate functionality in the node type reader and writer classes in Jackrabbit. Simple usage with the xsltproc tool from libxslt: $ xsltproc xml2cnd.xslt nodetypes.xml ... (outputs the CND node type definitions) BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development ?xml version=1.0? !-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:output method=text indent=no/ xsl:strip-space elements=*/ xsl:template match=nodeType xsl:text[/xsl:text xsl:value-of select=@name/ xsl:text]/xsl:text xsl:apply-templates select=supertypes[supertype]/ xsl:if test=@isMixin='true' xsl:text mixin/xsl:text /xsl:if xsl:if test=@hasOrderableChildNodes='true' xsl:text orderable/xsl:text /xsl:if xsl:text /xsl:text xsl:apply-templates select=propertyDefinition/ xsl:apply-templates select=childNodeDefinition/ xsl:text /xsl:text /xsl:template xsl:template match=supertypes xsl:text gt; /xsl:text xsl:apply-templates select=supertype/ /xsl:template xsl:template match=supertype xsl:if test=position() 1 xsl:text, /xsl:text /xsl:if xsl:value-of select=./ /xsl:template xsl:template match=propertyDefinition xsl:text - /xsl:text xsl:value-of select=@name/ xsl:text (/xsl:text xsl:value-of select=@requiredType/ xsl:text)/xsl:text xsl:apply-templates select=defaultValues[defaultValue]/ xsl:if test=../@primaryItemName = @name xsl:text primary/xsl:text /xsl:if xsl:if test=@autoCreated='true' xsl:text autocreated/xsl:text /xsl:if xsl:if test=@mandatory='true' xsl:text mandatory/xsl:text /xsl:if xsl:if test=@protected='true' xsl:text protected/xsl:text /xsl:if xsl:if test=@multiple='true' xsl:text multiple/xsl:text /xsl:if xsl:if test=@onParentVersion xsl:text /xsl:text xsl:value-of select=@onParentVersion/ /xsl:if xsl:apply-templates select=valueConstraints[valueConstraint]/ xsl:text /xsl:text /xsl:template xsl:template match=defaultValues xsl:text = /xsl:text xsl:apply-templates select=defaultValue/ /xsl:template xsl:template match=defaultValue xsl:if test=position() 1 xsl:text, /xsl:text /xsl:if xsl:value-of select=./ /xsl:template xsl:template match=valueConstraints xsl:text lt; /xsl:text xsl:apply-templates select=valueConstraint/ /xsl:template xsl:template match=valueConstraint xsl:if test=position() 1 xsl:text, /xsl:text /xsl:if xsl:value-of select=./ /xsl:template xsl:template match=childNodeDefinition xsl:text + /xsl:text xsl:value-of select=@name/ xsl:text (/xsl:text xsl:apply-templates select=requiredPrimaryTypes/requiredPrimaryType/ xsl:text)/xsl:text xsl:if test=@defaultPrimaryType xsl:text = /xsl:text xsl:value-of select=@defaultPrimaryType/ /xsl:if xsl:if test=../@primaryItemName = @name xsl:text primary/xsl:text /xsl:if xsl:if test=@autoCreated='true' xsl:text autocreated/xsl:text /xsl:if xsl:if test=@mandatory='true' xsl:text mandatory/xsl:text /xsl:if xsl:if test=@protected='true' xsl:text protected/xsl:text /xsl:if xsl:if test=@sameNameSiblings='true' xsl:text multiple/xsl:text /xsl:if xsl:if test=@onParentVersion
[jira] Updated: (JCR-392) Accessing element by number does not work
[ http://issues.apache.org/jira/browse/JCR-392?page=all ] Jukka Zitting updated JCR-392: -- Fix Version/s: (was: 1.1) Accessing element by number does not work - Key: JCR-392 URL: http://issues.apache.org/jira/browse/JCR-392 Project: Jackrabbit Issue Type: Bug Components: query Affects Versions: 1.0, 1.0.1, 0.9 Environment: svn version 393179M Reporter: Oliver Wehrens Assigned To: Marcel Reutegger I have a bunch of wiki:entries stored in my workspace. If I create the following code: q = qm.createQuery(//wiki:entry[5], Query.XPATH); qr = q.execute(); NodeIterator it = qr.getNodes(); The Nodeiterator reports all entries back, bot just the 5th. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-301) Improve the JCR-RMI Value classes
[ http://issues.apache.org/jira/browse/JCR-301?page=all ] Jukka Zitting updated JCR-301: -- Fix Version/s: (was: 1.1) Improve the JCR-RMI Value classes - Key: JCR-301 URL: http://issues.apache.org/jira/browse/JCR-301 Project: Jackrabbit Issue Type: Improvement Components: rmi Reporter: Jukka Zitting Assigned To: Jukka Zitting Investigate the possibility to reuse code from jackrabbit-commons in the JCR-RMI Value classes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-302) Use remote callbacks instead of polling for observation over JCR-RMI
[ http://issues.apache.org/jira/browse/JCR-302?page=all ] Jukka Zitting updated JCR-302: -- Fix Version/s: (was: 1.1) Use remote callbacks instead of polling for observation over JCR-RMI Key: JCR-302 URL: http://issues.apache.org/jira/browse/JCR-302 Project: Jackrabbit Issue Type: Improvement Components: observation Reporter: Jukka Zitting Assigned To: Jukka Zitting JCR-RMI currently uses polling to handle remote observation events. Change the implementation to use remote callbacks instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-415) Enhance indexing of binary content
[ http://issues.apache.org/jira/browse/JCR-415?page=all ] Jukka Zitting updated JCR-415: -- Fix Version/s: (was: 1.1) Enhance indexing of binary content -- Key: JCR-415 URL: http://issues.apache.org/jira/browse/JCR-415 Project: Jackrabbit Issue Type: Improvement Components: indexing Affects Versions: 1.0, 1.0.1, 0.9 Reporter: Marcel Reutegger Priority: Minor Attachments: jackrabbit-extractor-r420472.patch, jackrabbit-query-r420472.patch, jackrabbit-query-r421461.patch, org.apache.jackrabbit.core.query-extractor.jpg, org.apache.jackrabbit.core.query.lucene-extractor.jpg, org.apache.jackrabbit.extractor.jpg Indexing of binary content should be enhanced in order to allow either configuration what fields are indexed or provide better support for custom NodeIndexer implementations. The current design has a couple of flaws that should be addressed at the same time: - Reader instances are requested from the text filters even though the reader might never be used - only jcr:data properties of nt:resource nodes are fulltext indexed - It is up to the text filter implementation to decide the lucene field name for the text representation, responsibility should be moved to the NodeIndexer. A text filter should only provide a Reader instance. With those changes a custom NodeIndexer can then decide if a binary property has one or more representations in the index. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-151) Installation guide
[ http://issues.apache.org/jira/browse/JCR-151?page=all ] Jukka Zitting updated JCR-151: -- Fix Version/s: (was: 1.1) Priority: Major (was: Minor) Installation guide -- Key: JCR-151 URL: http://issues.apache.org/jira/browse/JCR-151 Project: Jackrabbit Issue Type: Improvement Components: docs Reporter: Jukka Zitting Assigned To: Jukka Zitting The current Jackrabbit installation instructions are spread across a number of different documents that each have a specific goal in mind. It would be great to have a single installation document that would list the installation dependencies and the available configuration options. More specific documents could then just refer to this installation guide for more details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-241) Remapping the default namespace
[ http://issues.apache.org/jira/browse/JCR-241?page=all ] Jukka Zitting updated JCR-241: -- Fix Version/s: (was: 1.1) Remapping the default namespace --- Key: JCR-241 URL: http://issues.apache.org/jira/browse/JCR-241 Project: Jackrabbit Issue Type: Wish Components: namespace Reporter: Jukka Zitting Priority: Minor I'm not sure if this is a bug, feature or standard behaviour, but currently it is not possible to remap the default namespace to some other prefix. The following code throws a NamespaceException: session.setNamespacePrefix(foo, ); At least the Session.setNamespacePrefix() javadoc doesn't seem to prohibit changing the prefix of the default namespace and I couldn't find anything more specific in the JCR specification document. Restrictions are only placed on remapping the xml namespace. Note that the current nodetype code is actually relying on the default namespace being mapped to the empty prefix, so changing this would require small changes there as well. I haven't really run into any cases where I'd have needed such functionality, but it would be nice to clarify this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-517) Reserved status of namespace jcr not enforced.
[ http://issues.apache.org/jira/browse/JCR-517?page=all ]
Jukka Zitting updated JCR-517:
--
Affects Version/s: 0.9
1.0
1.0.1
(was: 1.1)
Reserved status of namespace jcr not enforced.
--
Key: JCR-517
URL: http://issues.apache.org/jira/browse/JCR-517
Project: Jackrabbit
Issue Type: Bug
Components: versioning
Affects Versions: 1.0, 0.9, 1.0.1
Reporter: Peeter Piegaze
Priority: Minor
Fix For: 1.1
The failure to enforce the reserved status of the jcr namespace leads to at
least one problem.
A versionable node can be created with properties jcr:frozenPrimaryType,
jcr:frozenMixinTypes or jcr:frozenUuid. These clash with the meta-data
properties used in the nt:frozenNode.
When the versionable is checked-in and then later restored, the corrupt
frozen node can cause an exception. The following code demonstrates the
problem:
code
Repository repository = new TransientRepository();
Session session = repository.login(new SimpleCredentials(username,
password.toCharArray()));
try {
Node root = session.getRootNode();
Node a = root.addNode(a, nt:unstructured);
a.addMixin(mix:versionable);
a.setProperty(jcr:frozenMixinTypes, new String[]{x});
session.save();
Version v = a.checkin();
a.checkout();
a.remove();
session.save();
root.restore(v, a, true);
} finally {
session.logout();
}
/code
The solution is to enforce the reserved status of jcr (and nt, mix and xml,
while we are at it). The rules should be:
1) A client cannot register a node type that uses reserved namespaces in
either the name of the node type or in the name of any off its child item
definitions.
2) A client cannot create a residual child item with a name that uses a
reserved namespace. Clients can, of course, create an item with a reserved
namespace if the item is defined in a built-in JCR node type.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-134) Unreferenced VersionHistory should be deleted automatically.
[ http://issues.apache.org/jira/browse/JCR-134?page=all ] Jukka Zitting updated JCR-134: -- Fix Version/s: (was: 1.1) Unreferenced VersionHistory should be deleted automatically. Key: JCR-134 URL: http://issues.apache.org/jira/browse/JCR-134 Project: Jackrabbit Issue Type: New Feature Components: versioning Reporter: Tobias Bocanegra Assigned To: Tobias Bocanegra Priority: Minor since the creation of a VersionHistory is triggered by the creation of a mix:versionable node, the removal should happen automatically, as soon as no references to that version histroy exist anymore. this is the case, when all mix:versionable nodes (in all workspaces) belonging to that VH are deleted, and all the versions in the VH are removed i.e. only the jcr:rootVersion is left. At this point, the VH should be deleted aswell. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-303) Add JCR-RMI documentation to the Jackrabbit web site
[ http://issues.apache.org/jira/browse/JCR-303?page=all ]
Jukka Zitting updated JCR-303:
--
Fix Version/s: (was: 1.1)
Add JCR-RMI documentation to the Jackrabbit web site
Key: JCR-303
URL: http://issues.apache.org/jira/browse/JCR-303
Project: Jackrabbit
Issue Type: New Feature
Components: docs
Reporter: Jukka Zitting
Assigned To: Jukka Zitting
Priority: Minor
Use the org.apache.jackrabbit.rmi.{client,server} package javadocs as a base
for a JCR-RMI document page on the Jackrabbit web site.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-300) Streamline the JCR-RMI network interfaces
[ http://issues.apache.org/jira/browse/JCR-300?page=all ] Jukka Zitting updated JCR-300: -- Fix Version/s: (was: 1.1) Streamline the JCR-RMI network interfaces - Key: JCR-300 URL: http://issues.apache.org/jira/browse/JCR-300 Project: Jackrabbit Issue Type: Improvement Components: rmi Reporter: Jukka Zitting Assigned To: Jukka Zitting Priority: Minor The JCR-RMI network layer makes an excessive amount of remote method calls in some use cases. Use caching and other mechanisms to improve performance in such cases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-464) Prevent out of memory errors
[ http://issues.apache.org/jira/browse/JCR-464?page=all ] Jukka Zitting updated JCR-464: -- Fix Version/s: (was: 1.1) Prevent out of memory errors Key: JCR-464 URL: http://issues.apache.org/jira/browse/JCR-464 Project: Jackrabbit Issue Type: Improvement Components: core Affects Versions: 1.0, 1.0.1, 0.9 Reporter: Edgar Poce Priority: Minor Even an anonymous session can kill the jvm, any session can perform write actions untill it kills the process by causing an outofmemoryexception. I think it would be good to add a configuration parameter to specify the max size of the transient ISMs and the max number of sessions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (JCR-530) Add files generated by eclipse or maven to svn:ignore
[ http://issues.apache.org/jira/browse/JCR-530?page=all ] Jukka Zitting reassigned JCR-530: - Assignee: Jukka Zitting Add files generated by eclipse or maven to svn:ignore - Key: JCR-530 URL: http://issues.apache.org/jira/browse/JCR-530 Project: Jackrabbit Issue Type: Task Components: maven Reporter: Christoph Kiehl Assigned To: Jukka Zitting To make life easier for eclipse and maven users please add the following files to svn:ingore: jackrabbit-jcr-rmi: --- .settings .classpath .project jackrabbit-jcr-rmi-pom-snapshot-version project.xml.md5 jackrabbit-core: .settings .classpath .project jackrabbit-core-pom-snapshot-version project.xml.md5 Maybe there some files missing in this list that could help developers using IDEA? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-530) Add files generated by eclipse or maven to svn:ignore
[ http://issues.apache.org/jira/browse/JCR-530?page=all ] Jukka Zitting updated JCR-530: -- Component/s: maven Priority: Minor (was: Major) Add files generated by eclipse or maven to svn:ignore - Key: JCR-530 URL: http://issues.apache.org/jira/browse/JCR-530 Project: Jackrabbit Issue Type: Task Components: maven Reporter: Christoph Kiehl Assigned To: Jukka Zitting Priority: Minor To make life easier for eclipse and maven users please add the following files to svn:ingore: jackrabbit-jcr-rmi: --- .settings .classpath .project jackrabbit-jcr-rmi-pom-snapshot-version project.xml.md5 jackrabbit-core: .settings .classpath .project jackrabbit-core-pom-snapshot-version project.xml.md5 Maybe there some files missing in this list that could help developers using IDEA? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Apache Jackrabbit 1.1 release plan
Hi, This is the release plan for Apache Jackrabbit version 1.1. Unless anyone objects, I will assume lazy consensus on my continuing role as the release manager. I've just gone through the Jira issue list for 1.1 and postponed a number of issues that I don't think can make it for this release. There are already almost a hundred resolved issues since 1.0.1 so I don't think there is any need to wait for any specific issue to make it in 1.1. Release early, release often. The 1.1 release will be an incremental improvement over the 1.0 and 1.0.1 releases, with main focus on a number of bug fixes and minor new features. The most notable change from a deployment point of view is probably the removal of the Xerces dependency from the Jackrabbit core. REMAINING ISSUES For now I've left the following issues marked for the 1.1 release, mostly because I think they can be fixed fairly easily or because I don't know the exact status of the issues. However, none of these issues are critical for the release. [JCR-517] Reserved status of namespace jcr not enforced. [JCR-463] Uncommitted changes or connection leak with Container Managed ... [JCR-449] inconsistency in internal version items during commits [JCR-446] Prevent logins during repository shutdown [JCR-441] Session logout doesn't release locks acquired using addLockToken [JCR-435] Node.update() does not work correct for SNS [JCR-419] Request for other RMI binding options in RepositoryStartupServlet [JCR-320] BinaryValue equals fails for two objects with two different ... [JCR-314] Fine grained locking in SharedItemStateManager [JCR-43] Restore on node creates same-name-sibling of OPV-Version child ... [JCR-18] Multithreading issue with versioning Most notably I decided to postpone both the Maven 2.0 and Lucene 2.0 transitions originally targeted for the 1.1 release. Both these efforts have progressed slower than I originally planned, and at this point I don't feel comfortable making too drastic changes. We'll make those transitions later on. Please let me know about any issues you'd like to see included in 1.1 or that you think would better be postponed. RELEASE SCHEDULE I will create the 1.1 branch on Sunday 17th and create the first release candidates. At that time I will also review the list of open issues targeted for 1.1 and decide whether there are still some open issues that should make it in the release. Unless any major issues occur, I hope to start the release vote during the following week and publish the approved release during the week after that, at the end of September. Note that this schedule is still subject to change. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
