[jira] Commented: (JCR-1852) session.exportDocumentView() does not work with jaxb 2.1.x UnmarshallerHandler
[ https://issues.apache.org/jira/browse/JCR-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648574#action_12648574 ] Alex Lukin commented on JCR-1852: - I found that NPE is caused by namespace with empty prefix and empty uri. This namespace exists even in newly created repository. Code to discover it: String[] nsp = ses.getNamespacePrefixes(); for (String ns : nsp) { System.out.println( namespace: + ns + uri: + ses.getNamespaceURI(ns)); } session.exportDocumentView() does not work with jaxb 2.1.x UnmarshallerHandler --- Key: JCR-1852 URL: https://issues.apache.org/jira/browse/JCR-1852 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-commons Affects Versions: 1.5.0 Environment: jdk 1.6.10 Linux Reporter: Alex Lukin Original Estimate: 3h Remaining Estimate: 3h I tried to update my project from Jackrabbit 1.4 to 1.5 and found following error, that is critical for my app. Project uses Import/Export features of JCR and JAXB to map XML from JCR to java objects. exportDocumentView() works with streams when I call it like this: Unmarshaller umr = getUnmarshaller(); ... fo = new FileOutputStream(/tmp/export-node.xml); jcrs.exportDocumentView(path,fo , false, false); fi = new FileInputStream(/tmp/export-node.xml); umr.unmarshal(new InputSource(fi)); But it does not work when I call it using SAX event handler: UnmarshallerHandler ctxh = umr.getUnmarshallerHandler(); jcrs.exportDocumentView(path, ctxh, false, false); giving following exception: java.lang.NullPointerException at org.xml.sax.helpers.AttributesImpl.getIndex(AttributesImpl.java:203) at com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor$AttributesImpl.getIndex(InterningXmlVisitor.java:112) at com.sun.xml.bind.v2.runtime.unmarshaller.XsiNilLoader.selectLoader(XsiNilLoader.java:62) at com.sun.xml.bind.v2.runtime.unmarshaller.ProxyLoader.startElement(ProxyLoader.java:53) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:449) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:427) at com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor.startElement(InterningXmlVisitor.java:71) at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:137) at org.apache.jackrabbit.commons.xml.Exporter.startElement(Exporter.java:438) at org.apache.jackrabbit.commons.xml.DocumentViewExporter.exportNode(DocumentViewExporter.java:76) at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:298) at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:214) at org.apache.jackrabbit.commons.xml.DocumentViewExporter.exportNode(DocumentViewExporter.java:77) at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:298) at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:214) at org.apache.jackrabbit.commons.xml.DocumentViewExporter.exportNode(DocumentViewExporter.java:77) at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:298) at org.apache.jackrabbit.commons.xml.Exporter.export(Exporter.java:144) at org.apache.jackrabbit.commons.AbstractSession.export(AbstractSession.java:461) at org.apache.jackrabbit.commons.AbstractSession.exportDocumentView(AbstractSession.java:241) at ua.org.dg.semaril.helpers.AbstractTypeResolver.getContent(AbstractTypeResolver.java:31 Version 1.4. works fine. Jukka, please check your changes to org.apache.jackrabbit.commons.xml.Exporter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1852) session.exportDocumentView() does not work with jaxb 2.1.x UnmarshallerHandler
[ https://issues.apache.org/jira/browse/JCR-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648721#action_12648721 ] Alex Lukin commented on JCR-1852: - Thak you very much, my app works as it should. I just moved file from trunk to 1.5 branch, compiled commons and replaced in my app libs. Everything works fine. Pleas include this fix in 1.5 release. session.exportDocumentView() does not work with jaxb 2.1.x UnmarshallerHandler --- Key: JCR-1852 URL: https://issues.apache.org/jira/browse/JCR-1852 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-commons Affects Versions: 1.5.0 Environment: jdk 1.6.10 Linux Reporter: Alex Lukin Assignee: Jukka Zitting Fix For: 1.5.0 Original Estimate: 3h Remaining Estimate: 3h I tried to update my project from Jackrabbit 1.4 to 1.5 and found following error, that is critical for my app. Project uses Import/Export features of JCR and JAXB to map XML from JCR to java objects. exportDocumentView() works with streams when I call it like this: Unmarshaller umr = getUnmarshaller(); ... fo = new FileOutputStream(/tmp/export-node.xml); jcrs.exportDocumentView(path,fo , false, false); fi = new FileInputStream(/tmp/export-node.xml); umr.unmarshal(new InputSource(fi)); But it does not work when I call it using SAX event handler: UnmarshallerHandler ctxh = umr.getUnmarshallerHandler(); jcrs.exportDocumentView(path, ctxh, false, false); giving following exception: java.lang.NullPointerException at org.xml.sax.helpers.AttributesImpl.getIndex(AttributesImpl.java:203) at com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor$AttributesImpl.getIndex(InterningXmlVisitor.java:112) at com.sun.xml.bind.v2.runtime.unmarshaller.XsiNilLoader.selectLoader(XsiNilLoader.java:62) at com.sun.xml.bind.v2.runtime.unmarshaller.ProxyLoader.startElement(ProxyLoader.java:53) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:449) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:427) at com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor.startElement(InterningXmlVisitor.java:71) at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:137) at org.apache.jackrabbit.commons.xml.Exporter.startElement(Exporter.java:438) at org.apache.jackrabbit.commons.xml.DocumentViewExporter.exportNode(DocumentViewExporter.java:76) at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:298) at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:214) at org.apache.jackrabbit.commons.xml.DocumentViewExporter.exportNode(DocumentViewExporter.java:77) at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:298) at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:214) at org.apache.jackrabbit.commons.xml.DocumentViewExporter.exportNode(DocumentViewExporter.java:77) at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:298) at org.apache.jackrabbit.commons.xml.Exporter.export(Exporter.java:144) at org.apache.jackrabbit.commons.AbstractSession.export(AbstractSession.java:461) at org.apache.jackrabbit.commons.AbstractSession.exportDocumentView(AbstractSession.java:241) at ua.org.dg.semaril.helpers.AbstractTypeResolver.getContent(AbstractTypeResolver.java:31 Version 1.4. works fine. Jukka, please check your changes to org.apache.jackrabbit.commons.xml.Exporter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1852) session.exportDocumentView() does not work with jaxb 2.1.x UnmarshallerHandler
[ https://issues.apache.org/jira/browse/JCR-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12647271#action_12647271 ] Alex Lukin commented on JCR-1852: - I checked it with native java 1.6 jaxb implementation, result is the same. session.exportDocumentView() does not work with jaxb 2.1.x UnmarshallerHandler --- Key: JCR-1852 URL: https://issues.apache.org/jira/browse/JCR-1852 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-commons Affects Versions: 1.5.0 Environment: jdk 1.6.10 Linux Reporter: Alex Lukin Original Estimate: 3h Remaining Estimate: 3h I tried to update my project from Jackrabbit 1.4 to 1.5 and found following error, that is critical for my app. Project uses Import/Export features of JCR and JAXB to map XML from JCR to java objects. exportDocumentView() works with streams when I call it like this: Unmarshaller umr = getUnmarshaller(); ... fo = new FileOutputStream(/tmp/export-node.xml); jcrs.exportDocumentView(path,fo , false, false); fi = new FileInputStream(/tmp/export-node.xml); umr.unmarshal(new InputSource(fi)); But it does not work when I call it using SAX event handler: UnmarshallerHandler ctxh = umr.getUnmarshallerHandler(); jcrs.exportDocumentView(path, ctxh, false, false); giving following exception: java.lang.NullPointerException at org.xml.sax.helpers.AttributesImpl.getIndex(AttributesImpl.java:203) at com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor$AttributesImpl.getIndex(InterningXmlVisitor.java:112) at com.sun.xml.bind.v2.runtime.unmarshaller.XsiNilLoader.selectLoader(XsiNilLoader.java:62) at com.sun.xml.bind.v2.runtime.unmarshaller.ProxyLoader.startElement(ProxyLoader.java:53) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:449) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:427) at com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor.startElement(InterningXmlVisitor.java:71) at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:137) at org.apache.jackrabbit.commons.xml.Exporter.startElement(Exporter.java:438) at org.apache.jackrabbit.commons.xml.DocumentViewExporter.exportNode(DocumentViewExporter.java:76) at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:298) at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:214) at org.apache.jackrabbit.commons.xml.DocumentViewExporter.exportNode(DocumentViewExporter.java:77) at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:298) at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:214) at org.apache.jackrabbit.commons.xml.DocumentViewExporter.exportNode(DocumentViewExporter.java:77) at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:298) at org.apache.jackrabbit.commons.xml.Exporter.export(Exporter.java:144) at org.apache.jackrabbit.commons.AbstractSession.export(AbstractSession.java:461) at org.apache.jackrabbit.commons.AbstractSession.exportDocumentView(AbstractSession.java:241) at ua.org.dg.semaril.helpers.AbstractTypeResolver.getContent(AbstractTypeResolver.java:31 Version 1.4. works fine. Jukka, please check your changes to org.apache.jackrabbit.commons.xml.Exporter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1852) session.exportDocumentView() does not work with jaxb 2.1.x UnmarshallerHandler
session.exportDocumentView() does not work with jaxb 2.1.x UnmarshallerHandler --- Key: JCR-1852 URL: https://issues.apache.org/jira/browse/JCR-1852 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-commons Affects Versions: 1.5.0 Environment: jdk 1.6.10 Linux Reporter: Alex Lukin I tried to update my project from Jackrabbit 1.4 to 1.5 and found following error, that is critical for my app. Project uses Import/Export features of JCR and JAXB to map XML from JCR to java objects. exportDocumentView() works with streams when I call it like this: Unmarshaller umr = getUnmarshaller(); ... fo = new FileOutputStream(/tmp/export-node.xml); jcrs.exportDocumentView(path,fo , false, false); fi = new FileInputStream(/tmp/export-node.xml); umr.unmarshal(new InputSource(fi)); But it does not work when I call it using SAX event handler: UnmarshallerHandler ctxh = umr.getUnmarshallerHandler(); jcrs.exportDocumentView(path, ctxh, false, false); giving following exception: java.lang.NullPointerException at org.xml.sax.helpers.AttributesImpl.getIndex(AttributesImpl.java:203) at com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor$AttributesImpl.getIndex(InterningXmlVisitor.java:112) at com.sun.xml.bind.v2.runtime.unmarshaller.XsiNilLoader.selectLoader(XsiNilLoader.java:62) at com.sun.xml.bind.v2.runtime.unmarshaller.ProxyLoader.startElement(ProxyLoader.java:53) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:449) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:427) at com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor.startElement(InterningXmlVisitor.java:71) at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:137) at org.apache.jackrabbit.commons.xml.Exporter.startElement(Exporter.java:438) at org.apache.jackrabbit.commons.xml.DocumentViewExporter.exportNode(DocumentViewExporter.java:76) at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:298) at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:214) at org.apache.jackrabbit.commons.xml.DocumentViewExporter.exportNode(DocumentViewExporter.java:77) at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:298) at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:214) at org.apache.jackrabbit.commons.xml.DocumentViewExporter.exportNode(DocumentViewExporter.java:77) at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:298) at org.apache.jackrabbit.commons.xml.Exporter.export(Exporter.java:144) at org.apache.jackrabbit.commons.AbstractSession.export(AbstractSession.java:461) at org.apache.jackrabbit.commons.AbstractSession.exportDocumentView(AbstractSession.java:241) at ua.org.dg.semaril.helpers.AbstractTypeResolver.getContent(AbstractTypeResolver.java:31 Version 1.4. works fine. Jukka, please check your changes to org.apache.jackrabbit.commons.xml.Exporter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1467) Hide ugly repository init code for OCM
[ https://issues.apache.org/jira/browse/JCR-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578876#action_12578876 ] Alex Lukin commented on JCR-1467: - Thnks, it works fine at least in my case. I removed init code an my project passed tests. I do not use restrictive node types so I did not checked case b. Hide ugly repository init code for OCM -- Key: JCR-1467 URL: https://issues.apache.org/jira/browse/JCR-1467 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-ocm Environment: All Reporter: Alex Lukin Assignee: Christophe Lombart Fix For: 1.5 Attachments: jackrabbit-OCM-repoinit.patch Original Estimate: 1h Remaining Estimate: 1h Hide repository namespace registration and ocm:discriminator node type registration in implementation of OCM -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1467) Hide ugly repository init code for OCM
Hide ugly repository init code for OCM -- Key: JCR-1467 URL: https://issues.apache.org/jira/browse/JCR-1467 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-ocm Environment: All Reporter: Alex Lukin Fix For: 1.5 Hide repository namespace registration and ocm:discriminator node type registration in implementation of OCM -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1467) Hide ugly repository init code for OCM
[ https://issues.apache.org/jira/browse/JCR-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Lukin updated JCR-1467: Attachment: jackrabbit-OCM-repoinit.patch This patch applies only to implememntation code. It's upt to author of OCM to put it into interface Hide ugly repository init code for OCM -- Key: JCR-1467 URL: https://issues.apache.org/jira/browse/JCR-1467 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-ocm Environment: All Reporter: Alex Lukin Fix For: 1.5 Attachments: jackrabbit-OCM-repoinit.patch Original Estimate: 1h Remaining Estimate: 1h Hide repository namespace registration and ocm:discriminator node type registration in implementation of OCM -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1404) javadoc writing and generation with mvn
javadoc writing and generation with mvn --- Key: JCR-1404 URL: https://issues.apache.org/jira/browse/JCR-1404 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Environment: Linux sun jdk 1.6 Reporter: Alex Lukin Priority: Trivial Fix For: 1.5 mvn -source 1.5 javadoc:javadoc does not work because following lines must be added to pom.xml plugin artifactIdmaven-javadoc-plugin/artifactId configuration source1.5/source /configuration /plugin Please also write more comprehensive javadocs to allow better source understanding and developer co-operation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1365) Query path constraints like foo//*/bar do not scale
[ https://issues.apache.org/jira/browse/JCR-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567042#action_12567042 ] Alex Lukin commented on JCR-1365: - Most users do not bother with complicated XPath query to find nodes. Usually content modeled such way that node contains subnodes of one type. So query //foo/*/bar is quite common. Speed of this query is simply depressive. 200 nodes in 3 levels makes debugger think on query.execute() for minutes and then minutes on getting trough iterator. IMHO, it is high priority task.I've herad a lot of bad words from colleagues about Lucene in general and about Lucene in Jackrabbit and I think that the cause of all it is bad speed on such simple queries. Query path constraints like foo//*/bar do not scale --- Key: JCR-1365 URL: https://issues.apache.org/jira/browse/JCR-1365 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Marcel Reutegger Priority: Minor To resolve the * step the LuceneQueryBuilder currently creates a MatchAllQuery and checks every node for a foo ancestor. Instead, it should search for bar nodes and check for foo ancestors with at least one arbitrary hierarchy level in between. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-1365) Query path constraints like foo//*/bar do not scale
[ https://issues.apache.org/jira/browse/JCR-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567042#action_12567042 ] alukin edited comment on JCR-1365 at 2/8/08 6:00 AM: - Most users do not bother with complicated XPath query to find nodes. Usually content modeled such way that node contains subnodes of one type. So query //foo/*/bar is quite common. Speed of this query is simply depressive. 200 nodes in 3 levels makes debugger think on query.execute() for minutes and then minutes on getting trough iterator. IMHO, it is high priority task.I've herad a lot of bad words from colleagues about Lucene in general and about Lucene in Jackrabbit and I think that the cause of all it is bad speed on such simple queries. May be It would be nice to be abble start guery not for entire workplace but for some node? Could it speedup search? was (Author: alukin): Most users do not bother with complicated XPath query to find nodes. Usually content modeled such way that node contains subnodes of one type. So query //foo/*/bar is quite common. Speed of this query is simply depressive. 200 nodes in 3 levels makes debugger think on query.execute() for minutes and then minutes on getting trough iterator. IMHO, it is high priority task.I've herad a lot of bad words from colleagues about Lucene in general and about Lucene in Jackrabbit and I think that the cause of all it is bad speed on such simple queries. Query path constraints like foo//*/bar do not scale --- Key: JCR-1365 URL: https://issues.apache.org/jira/browse/JCR-1365 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Marcel Reutegger Priority: Minor To resolve the * step the LuceneQueryBuilder currently creates a MatchAllQuery and checks every node for a foo ancestor. Instead, it should search for bar nodes and check for foo ancestors with at least one arbitrary hierarchy level in between. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1357) Create quick start developer bundles for model 1,2,3 deployment
Create quick start developer bundles for model 1,2,3 deployment - Key: JCR-1357 URL: https://issues.apache.org/jira/browse/JCR-1357 Project: Jackrabbit Issue Type: Improvement Affects Versions: 1.4 Environment: Linux/sun jdk 1.6.0 Reporter: Alex Lukin Priority: Critical Fix For: 1.4.1 Please create quick start developer bundles for deployment models 1,2,3 with all dependance libs and application startup code. Some kind of Hello, world app on models 1,2,3. Tomcat and jetty bundles would be nice. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1354) Repository shutdown reposts ERROR: failed to close connection
Repository shutdown reposts ERROR: failed to close connection - Key: JCR-1354 URL: https://issues.apache.org/jira/browse/JCR-1354 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.4 Environment: Linux x86/Sun jdk 1.6.0_3 Reporter: Alex Lukin Fix For: 1.4.1 Norman repository shutdow reports error twice in logs: ERROR: failed to close connection, reason: No current connection., state/code: 08003/4 ERROR: failed to close connection, reason: No current connection., state/code: 08003/4 Does not matter if there are not-closed sessions or not. Use od Derby of FS causes additional SQL exceptions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.