[jira] Commented: (JCR-690) Nodes' and properties' names with invalid XML characters export as invalid XML
[ http://issues.apache.org/jira/browse/JCR-690?page=comments#action_12460966 ] Jukka Zitting commented on JCR-690: --- The JSR 283 early draft only allows XML charactes in JCR names to solve this issue. I think we should adopt the same policy already now, since JSR 170 allows implementations to place custom restrictions on repository content. We should essentially add guards in the name parsing method to prevent invalid XML characters from being entered in JCR names. Nodes' and properties' names with invalid XML characters export as invalid XML -- Key: JCR-690 URL: http://issues.apache.org/jira/browse/JCR-690 Project: Jackrabbit Issue Type: Bug Components: xml Affects Versions: 1.1, 1.1.1 Reporter: Jan Kuzniak Session.exportSystemView method does check whether character should be escaped using _X_ pattern or not. It just puts it into XML without any validation. It causes e.g. XML attributes to contain entities like #0; -- 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-690) Nodes' and properties' names with invalid XML characters export as invalid XML
[ http://issues.apache.org/jira/browse/JCR-690?page=all ] Jukka Zitting updated JCR-690: -- Component/s: JSR 283 Priority: Minor (was: Major) Nodes' and properties' names with invalid XML characters export as invalid XML -- Key: JCR-690 URL: http://issues.apache.org/jira/browse/JCR-690 Project: Jackrabbit Issue Type: Bug Components: xml, JSR 283 Affects Versions: 1.1, 1.1.1 Reporter: Jan Kuzniak Priority: Minor Session.exportSystemView method does check whether character should be escaped using _X_ pattern or not. It just puts it into XML without any validation. It causes e.g. XML attributes to contain entities like #0; -- 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-674) String properties with invalid XML characters export as invalid XML
[ http://issues.apache.org/jira/browse/JCR-674?page=all ] Jukka Zitting updated JCR-674: -- Component/s: JCR 1.0.1 Priority: Minor (was: Major) String properties with invalid XML characters export as invalid XML --- Key: JCR-674 URL: http://issues.apache.org/jira/browse/JCR-674 Project: Jackrabbit Issue Type: Bug Components: xml, JCR 1.0.1 Affects Versions: 1.1.1 Reporter: Joshua Levy Priority: Minor As noted in the current JCR 1.0.1 maintenance draft, sections 6.4.1, 6.4.2.6, XML export of string properties that contain invalid XML characters isn't well-defined currently, since those characters are not permissible in XML. The proposed fix is to use base64 encoding for such values in System View. Most characters below #x20 are examples of this. Currently, these are escaped numerically in output (such as (amp)#0; ) but such escape sequences can't be parsed by the XML import methods. The current behavior is particularly problematic, because the user doesn't know the output is corrupt until later, when they try to import it and get InvalidSerializedDataException. If for some reason the base64 option is delayed, it might make sense, as an interim solution, to fail on export or to somehow patch import to relax its parsing and allow these escape codes. -- 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
JCR spec components in Jira
Hi, I've added the JCR 1.0.1 and JCR 2.0 components in the Jackrabbit issue tracker to better track changes related to the JSR 170 maintenance release and the JSR 283 specification. The spec component tags should always be associated with a structural tag that identifies the functional area that the issue is about. For example a request to impelement new versioning functionality specified in JSR 283 should be tagged with both versioning and JCR 2.0 components. BR, Jukka Zitting
Re: [jira] Commented: (JCR-680) Improve the Value implementation
Hi Jukka, So far I thought 'values' is quite a simple concept, and with some exceptions (for example the problems with streams) I thought it should be possible to implement it in a simple way. To tell you the truth, I don't understand the class diagram. For me, it is very complex, I'm confused. For example, I don't understand why you made the distinction between initial and committed values? Also I don't understand what GenericValue is for (specially the hashCode method of this class seems strange, it looks like it is very inefficient because it is always creates a String and doesn't cache the hash value). Other things that are inefficient are CommittedStringValue.getXYZ() because those methods always create Parser objects. But I just don't understand the concept, I'm not saying it is 'wrong' (maybe we can guarantee that these functions are not used a lot). By the way, one concept I don't currently see in the value factory implementation is caching of commonly used values (except for CommittedTrueValue / CommittedFalseValue). In my experience, this improves the performance and saves a lot of memory because it is very common that a small set of values is used in many places. I could implement such a feature later on if it is not implemented yet. SerializableInputStream: if I understand it correctly, then the old implementation allowed very large (that don't fit in memory) binary values, and the new implementation does not? Please correct me if I'm wrong. If this is would be correct, then for me this alone is reason enough not to apply the patch. I think the ability to store / retrieve very large binary values is very important. I understand it is 'better' not to create temp files on the client side (for speed for example, and to avoid security problems and avoid having to deal with creating / deleting temp files), but if you want to consume the value multiple times (for example, because it is used in multiple places), it is probably the easiest solution. Another case is for high availability clustering, if the value is sent to multiple servers (I understand there is no plan to support that in the near future). Please don't view my comments as critics. I just don't understand the concept behind it, and the reasons for doing the things like you did. I'm for adding the test cases of course! Test cases are always good. Thomas On 12/22/06, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On 12/22/06, Thomas Mueller [EMAIL PROTECTED] wrote: The rationale for proposing a revolutionary rewrite rather than incrementally improving the existing Value implementation is that the basic design of the existing implementation doesn't allow easy extension or customization. What kind of extension / customization do you have in mind? I'm just curious... SPI? SPI might be a good candidate, though I was especially thinking of implementations where you'd rather use a custom adapter to an internal value representation instead of one of the existing the committed value classes. The State pattern in the proposed implementation nicely separates the internal value representation from the value state behaviour, making it easy to implement custom value backends. For example, I've been thinking about a simple SystemViewRepository implementation that would expose a system view XML document through the JCR API. It would make sense for such an implementation to implement Values as adapters of the sv:value nodes in the DOM tree. the stream data is materialized in memory during de-/serialization; this renders it imo unusable for large streams. Value serialization should never be used by Jackrabbit core, it's included for other applications like JCR-RMI. So you mean the JCR-RMI would serialize streams? Does it do that now? JCR-RMI currently uses temporary files for deserialized binary values. I'm not too happy about that, a better approach would be to use a RemoteInputStream to stream the data over the network on-demand. More generally, is there another way to (more or less) efficiently access a JCR repository remotely and store / read streams, and what is the plan for the future? Or is this the goal of the SPI project (from what I read, I'm not sure any more)? I think the WebDAV server is already pretty good in that respect. Implementing the JCR API on top of the WebDAV interface is one of the goals of the SPI effort. The goal of the default implementation is full semantic accuracy without extra external dependencies (like to the file system) Currently I think that buffering really large (bigger than memory) streams to disk (temp file) on the client side is the easiest way to support them in a client / server environment. If you don't do that, then either you can't support large streams at all, or you need to implement special handling in the remote protocol. So you have the dependency there, and things get even more complicated and less modular compared to disk buffering. Just my
Re: [jira] Commented: (JCR-680) Improve the Value implementation
Hi, On 12/27/06, Thomas Mueller [EMAIL PROTECTED] wrote: So far I thought 'values' is quite a simple concept, and with some exceptions (for example the problems with streams) I thought it should be possible to implement it in a simple way. To tell you the truth, I don't understand the class diagram. For me, it is very complex, I'm confused. For example, I don't understand why you made the distinction between initial and committed values? I'm using the State pattern to localize the Value state transitions to the Generic and Initial value classes. The current approach keeps the state in an explicit BaseValue.state member value and requires explicit setValueConsumed() calls in subclasses to keep the state updated. The proposed implementation simplifies this by removing all state handling form the committed value classes, leaving only the responsibilities of value representation and conversion to the committed values. Also I don't understand what GenericValue is for (specially the hashCode method of this class seems strange, it looks like it is very inefficient because it is always creates a String and doesn't cache the hash value). GenericValue implements the context part of the State pattern. It is essentially a wrapper around the GenericValue.value member variable that points to the current Value state. The state can either be an initial value (in case a value getter has not yet been called) or a committed value (in case a getter has already been called). The difference between those states is that an initial value can still be converted from stream to non-stream or vice versa, but a committed value can not. Caching the hash value would of course be possible if better performance is required, but I don't think Values are used that much as hash keys, so I think that simplicity is more important in this case. The getString() call is required in hashCode() to achieve proper state behaviour and to comply with the equals() contract. Other things that are inefficient are CommittedStringValue.getXYZ() because those methods always create Parser objects. But I just don't understand the concept, I'm not saying it is 'wrong' (maybe we can guarantee that these functions are not used a lot). I wanted to localize the value conversion mechanisms as much as possible to avoid duplicating code. Since an instance of the ValueParser class is essentially just a wrapper for the String to be parsed, I would expect a decent JVM to optimize away the allocation of the object (or to just allocate it as a temporary object on stack). By the way, one concept I don't currently see in the value factory implementation is caching of commonly used values (except for CommittedTrueValue / CommittedFalseValue). In my experience, this improves the performance and saves a lot of memory because it is very common that a small set of values is used in many places. I could implement such a feature later on if it is not implemented yet. Good point, and actually something that couldn't be possible without separating the committed value state. It would be nice to see some performance numbers before doing that though, since a generational garbage collector allows amazingly good performance with large numbers of small objects. SerializableInputStream: if I understand it correctly, then the old implementation allowed very large (that don't fit in memory) binary values, and the new implementation does not? Please correct me if I'm wrong. You're wrong. The whole stream is consumed in memory only when a Value gets serialized, something that the current implementation doesn't even support. In any case both implementations are even required to consume the entire stream if getString() is called. In normal circumstances (i.e. only getStream() called on binary values), the proposed implementation simply passes along the InputStream received in ValueFactory.createValue(InputStream) just like the current implementation does. Note however that simply doing that in ValueFactory.createValue(InputStream) is most likely incorrect as the client that makes the call has currently no way of knowing when or who should close the stream to reclaim any resources (file handles, etc.) associated with the stream. The proposed Value implementation does not attempt to solve this isssue. PS. I should probably present the proposed changes as a sequence of incremental changes than as a single revolutionary patch. BR, Jukka Zitting
[jira] Updated: (JCR-680) Improve the Value implementation
[ http://issues.apache.org/jira/browse/JCR-680?page=all ] Jukka Zitting updated JCR-680: -- Attachment: GenericValue.patch Attached GenericValue.patch, that implements only the State pattern part of the proposed change. The patch is against Jackrabbit trunk, since the change affects both jackrabbit-core and jackrabbit-jcr-commons. This patch fixes JCR-320 and notably simplifies the Value classes. The changes in jackrabbit-core replace direct dependencies to the Value classes with use of Session.getValueFactory().createValue(). Improve the Value implementation Key: JCR-680 URL: http://issues.apache.org/jira/browse/JCR-680 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Jukka Zitting Assigned To: Jukka Zitting Priority: Minor Attachments: class.jpg, GenericValue.patch, JCR-680.patch The current Value implementation found in jackrabbit-jcr-commons has some deficiencies like Value.equals() being incorrect in some cases (see for example JCR-320), and Name and Path values not following namespace remappings. -- 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-688) Improve name resolution
[ http://issues.apache.org/jira/browse/JCR-688?page=all ] Jukka Zitting updated JCR-688: -- Attachment: JCR-688.LocalCache.patch Attached JCR-688.LocalCache.patch (against jackrabbit-core) that replaces the CachingNamespaceResolver in NamespaceRepository with a simple LRUMap in LocalNamespaceMappings. This achieves the same performance as before without any of the concurrence issues. It also works fine with local namespace remappings. Improve name resolution --- Key: JCR-688 URL: http://issues.apache.org/jira/browse/JCR-688 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Jukka Zitting Priority: Minor Fix For: 1.3 Attachments: JCR-688.LocalCache.patch As discussed in JCR-685, the current CachingNamespaceResolver class contains excessive synchronization causing monitor contention that reduces performance. In JCR-685 there's a proposed patch that replaces synchronization with a read-write lock that would allow concurrent read access to the name cache. -- 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] Commented: (JCR-688) Improve name resolution
[ http://issues.apache.org/jira/browse/JCR-688?page=comments#action_12461041 ] Julian Reschke commented on JCR-688: If we know that name prefix resolution causes this amount of pain, shouldn't we consider adding QName-based addressing in JSR-283? Improve name resolution --- Key: JCR-688 URL: http://issues.apache.org/jira/browse/JCR-688 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Jukka Zitting Priority: Minor Fix For: 1.3 Attachments: JCR-688.LocalCache.patch As discussed in JCR-685, the current CachingNamespaceResolver class contains excessive synchronization causing monitor contention that reduces performance. In JCR-685 there's a proposed patch that replaces synchronization with a read-write lock that would allow concurrent read access to the name cache. -- 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] Commented: (JCR-688) Improve name resolution
[ http://issues.apache.org/jira/browse/JCR-688?page=comments#action_12461047 ] Jukka Zitting commented on JCR-688: --- If we know that name prefix resolution causes this amount of pain, shouldn't we consider adding QName-based addressing in JSR-283? This issue is just a minor implementation detail. There is a price in performance of doing the String-QName conversions, but the performance hit is probably only noticeable for heavily cached workloads like the example above. The cost of the string operations is likely insignificant as soon as the repository starts hitting the disk. The reason I'm passionate about this is not the performance, but the creeping complexity introduced by the concurrency control. More generally I think the whole name resolution infrastructure in Jackrabbit is much more complex than it really needs to be. Improve name resolution --- Key: JCR-688 URL: http://issues.apache.org/jira/browse/JCR-688 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Jukka Zitting Priority: Minor Fix For: 1.3 Attachments: JCR-688.LocalCache.patch As discussed in JCR-685, the current CachingNamespaceResolver class contains excessive synchronization causing monitor contention that reduces performance. In JCR-685 there's a proposed patch that replaces synchronization with a read-write lock that would allow concurrent read access to the name cache. -- 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
Re: JCR-JMI problem .... please help
Hi Yaqeen, String name = rmi://192.168.1.6:1099/AcopianRep; This is not a correct URL to use for the ClientRepositoryFactory.getRepository(String url) method. The URL must be without the scheme, that is //192.168.1.6:1099/AcopianRep in your case. Hope this helps. Regards Felix
[jira] Created: (JCR-691) Let NameException extend RepositoryException
Let NameException extend RepositoryException Key: JCR-691 URL: http://issues.apache.org/jira/browse/JCR-691 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Jukka Zitting Priority: Minor Fix For: 1.3 Attachments: NameException.patch Since the NameExceptions (IllegalNameException, UnknownPrefixException, etc.) are typically thrown when parsing or formatting JCR names at the JCR API level, it would make sense for the NameException class to extend RepositoryException instead of the internal BaseException. This idea is supported by the fact that the majority of cases where NameExceptions are encountered simply rethrow the exceptions wrapped inside RepositoryException instances. Making NameException extend RepositoryException would reduce the amount of try-catch blocks and wrapped exceptions. -- 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-691) Let NameException extend RepositoryException
[ http://issues.apache.org/jira/browse/JCR-691?page=all ] Jukka Zitting updated JCR-691: -- Attachment: NameException.patch Attached NameException.patch (against trunk) that implements the proposed change and adjusts the code in jackrabbit-core accordingly. Let NameException extend RepositoryException Key: JCR-691 URL: http://issues.apache.org/jira/browse/JCR-691 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Jukka Zitting Priority: Minor Fix For: 1.3 Attachments: NameException.patch Since the NameExceptions (IllegalNameException, UnknownPrefixException, etc.) are typically thrown when parsing or formatting JCR names at the JCR API level, it would make sense for the NameException class to extend RepositoryException instead of the internal BaseException. This idea is supported by the fact that the majority of cases where NameExceptions are encountered simply rethrow the exceptions wrapped inside RepositoryException instances. Making NameException extend RepositoryException would reduce the amount of try-catch blocks and wrapped exceptions. -- 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
The exception about test report
The newest version has two exception in SQLPathTest. --- testDescendantTestRoot(org.apache.jackrabbit.test.api.query.SQLPathTest) junit.framework.AssertionFailedError: /testdata/serialization is not part of the result set at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.jackrabbit.test.api.query.AbstractQueryTest.checkResult(AbstractQueryTest.java:281) at org.apache.jackrabbit.test.api.query.AbstractQueryTest.executeSqlQuery(AbstractQueryTest.java:258) at org.apache.jackrabbit.test.api.query.SQLPathTest.testDescendantTestRoot(SQLPathTest.java:71) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:393) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) testChildAxisTestRoot(org.apache.jackrabbit.test.api.query.SQLPathTest) junit.framework.AssertionFailedError: /testdata/serialization is not part of the result set at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.jackrabbit.test.api.query.AbstractQueryTest.checkResult(AbstractQueryTest.java:281) at org.apache.jackrabbit.test.api.query.AbstractQueryTest.executeSqlQuery(AbstractQueryTest.java:258) at org.apache.jackrabbit.test.api.query.SQLPathTest.testChildAxisTestRoot(SQLPathTest.java:136) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:393) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) testDescendantTestRoot(org.apache.jackrabbit.test.api.query.SQLPathTest) junit.framework.AssertionFailedError: /testdata/serialization is not part of the result set at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.jackrabbit.test.api.query.AbstractQueryTest.checkResult(AbstractQueryTest.java:281) at org.apache.jackrabbit.test.api.query.AbstractQueryTest.executeSqlQuery(AbstractQueryTest.java:258) at org.apache.jackrabbit.test.api.query.SQLPathTest.testDescendantTestRoot(SQLPathTest.java:71) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at
