[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.
OCM: is project alive?
Hi, All! There's no commits in jackrabbit-ocm package for a long time and it does not compile after commit of jackrabbit security classes. Fix is trivial but question is not in fixing code. I'm starting another jackrabit-based project with OCM and I'd like to know what is going on with project. Is OCM still supported? Will it be fully integrated in jackrabbit build and release system? Are developers still in the team? I ought to say that OCM is very important part of jackrabbit project because it simplifies and speeds up development and just makes life easier. BTW, there's another implementation of OCM called JCROM (http://code.google.com/p/jcrom/) that moves forward very quickly, easier and better documented, but I just do not want use different implementations in my projects. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
Re: OCM: path as primary key is questionable
Hi! Sunday 16 March 2008 22:32:55 Christophe Lombart написав: So question is: why not to use UUID as primary key for OCM? In my opinion it is only one reliable key in JCR. OCM code may just force all OCM nodes to have jcr:uuid property and relay on it. For me, this is not a good idea because UUID is not mandatory in JCR. OCM is not mandatory by JCR too but this fact does not stop you from development. :) UUID is mentioned many many times in JSR-170 so it is madatory in JCR but optional for some nodes you do not care of. Referencial integrity is not possible without UUID. Implementation of JCR is not possible without UUID. Furthermore, you are forcing to apply the mixin type mix:referenceable to each node. Is it big deal? In your former implementation you forced ocm:discriminator mixin type for nodes with ugly type registration code. Node with mix:referenceable is quite better because it forces referncial integrity of node and developer can be sure that references to OCM nodes will be OK. What's bad wiht it? Imagine I move some node from user's home to public area. All references made to this node before move will be OK after move. I'm not sure this is a good idea for all use cases. I can tell you 5 uses cases where path is very questionable idea causing incosistences. Tell me one use case where UUID is bad. :) And by the way, UUID operations are 25-50% faster then path operations. Furthermore, UUID can be used as unique instance ID independent of node location. Fetching by UUID you can always return correct path for oubject. You can place object where you want. PS. Dear Christophe! Please do not think I criticize your implementation because I don't like it. There's anotgher solutions but I use yours. I just want make it better. Unfortunately, it takes time to catch up with code and I can't send you patch right today to check idea with UUID. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
OCM: path as primary key is questionable
Hi, All, hi, dear Cristphe! I know you are busy and I know I'm asking of impossible :) But I want to start discussion again. You use path as equivalent of primary key for OCM. I found a lot of incosistences in my appication that caused by such questionable approach. For instance, if I have some OCM mapped node with some bean subnodes and then get subnode by search operation, I can not update it because it's path is relative to top node. Things go even worse if I try to move nodes. JCR does not have concept of undreakable subtree so operations based on relative path will ever cause inconsistence. Another thihng that causes incovinience that I must define some property as (path=true) even if I do not need path. JCR has some features that keeps links and other things consistent. Those features I belive not based on path but on UUID. So question is: why not to use UUID as primary key for OCM? In my opinion it is only one reliable key in JCR. OCM code may just force all OCM nodes to have jcr:uuid property and relay on it. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
[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.
Re: OCM: why not to hide ugly init code?
Wednesday 12 March 2008 00:34:27 Christophe Lombart написав: Just one comment : The OCM has to be completely independent of Jackrabbit core. By this way, it can be used with other JCR implementation. As you can see, Jackrabbit core is only used for the unit tests. That's why the code is so ugly ... until there is a standard way to add new node types. I see. So my Jira Isuue and patch has to be deleted. Node type registration is standard in JSR-283 so we have to wait when it will be ready. Anyway, use of custom node types is not quite mandatory for OCM. It is possible to use some hidden property to store needed info. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
Re: OCM: why not to hide ugly init code?
Wednesday 12 March 2008 10:52:58 Christophe Lombart написав: If I understand you, your proposal is something like this : 1. If the class is mapped to the unstructured node type or a node type that gives you the possibility to add extra properties, create a new property ocm_classname. 2. If it is not possible to add this property due to strong constrains in the corresponding node type, try to add the mixin type ocm:discriminator (if necessary). Is it something like this ? Yes, exactly. I doubd pople are using restrictive node types in real life with OCM. Counting that jcr-1.0 does not support custom node types ... So it will be rather rare exception to use some mixin type to store mapping class info. For instance JCROM OCM implementation does not require any custom node registration. BTW, it easy maps binary content. See http://code.google.com/p/jcrom/ -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
OCM: why not to hide ugly init code?
Hi, All, Hi, Christophe! I just took a look at new OCM docs at http://jackrabbit.apache.org/5-with-jackrabbit-ocm.html I must say taht ugly init code for annotation based OCM may be and must be hidden. In my application I created needed xml file and placed it in same package where OCM init code is. Then I read it directly from jar using simple code below: InputStream xml = this.getClass().getResourceAsStream(nodetypes-ocm.xml); NodeTypeDef[] types = NodeTypeReader.read(xml); Rest of init code needs Session object with superuser rights (Oh! rights on jackrabbit! :) ) but it is not a big problem to create one built-in OCM method with session as parameter. In my opinion, current init code is conerproductive and creates bad attitude of user just by the first look of new OCM user. I can not imagine any reason to leave such code for end user. BTW, you forgot to mention in docs 3 not trivial dependencies for OCM: cglib-2.1_3.jar , asm-1.5.3.jar, commons-beanutils-1.7.0.jar I forgot to put libs for yet next OCM project so I just made a big sticker with shuch message on my desctop :) As allways, should I create Jira issue with this? -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
OCM query docs
Dear Christophe! I't trying to catch up with your source code to be able to help... and what I need is some authoritative javadocs explaining what methods must do. Could you please write few javadoc lines for Filter and Query interfaces in svn trunc? And please put following: plugin artifactIdmaven-javadoc-plugin/artifactId configuration source1.5/source /configuration /plugin in pom.xml of ocm module to allow javadoc generation. BTW, it does not create javadoc jar anyway... I do not want to create Jira issue for such a little task... -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
[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.
Re: jackrabbit-core 1.4.2 release plan
Hi, Jukka! I tested resolved issue 1365 (xpath query speedup) and it works perfect. It marked for 1.5 release but IMO not depends on other changes. Could you please include this solution in 1.4.2? -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
Re: jackrabbit-core 1.4.2 release plan
Thursday 21 February 2008 21:40:09 Jukka Zitting написав: Our policy has normally been to only include bug fixes in patch releases, so I'd rather wait for 1.5 until releasing JCR-1365. Is it bug fix: significant (10x times) speedup of terrible sluggish query? This patch does not change behavior or adds new feature. Please, find a way to include it in 1.4.2 if it is possiibe. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
OCM: inconsistent path parameter
Hi, all! When I get some objects from JCR by executing ocm.getObjects(query) and then try to update some of them by execution ocm.update(myObj), exception is thrown: javax.jcr.RepositoryException: not an absolute path: tratata Those objects are elements of mapped by OCM collections form higher level class. BTW, higer level class update works becaue it has absolute path set at creation time. Paths of collection elements are automatically generated by OCM. As I understand from previous discussion, path in OCM is some kind of unique primary key so I should be able retrieve OCM object by any operation, modify it ant then save. If I do not modyfy path, operation must be simple. As I said before, path is not good candidate for primary key but anyway behavior of OCM must be cosistent. If I get some object I sould be able modify and update it at the same place without any troubles. May be simpliest solution in this case is absolute path but I do not know how it will work with versionong and etc. Fortunately this inconsistent behavior is not critical in my case because all my objects placed under one node. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
Re: Same name siblings
Friday 08 February 2008 17:44:41 Thomas Mueller написав: Hi, I would drop it with migration path. Example: Converting old repositories or xml with same name siblings will convert the composed name to literal names, that means: two nodes 'test' are converted to 'test[1]' and 'test[2]'; removing 'test[1] will not rename 'test[2]' to 'test[1]'. +1 XML import requires SNS support so it can not be droped. This idea sounds very resonable but what about XML export? Thus we have to restrict use of that kind of path names and all such nodes with indexes at the end will be interpeted as SNS. Another bad thing that new nodes must be added after last number used, even if that node already deleted. We want reliable paths I think. So we must keep this info somewhere and delete it after last SNS with the name is deleted. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
[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.
Re: [OCM] The ocm:discriminator
Thursday 07 February 2008 15:25:44 Christophe Lombart написав: [skiped] If I can do it, the mixin node type ocm:disciminator is not necessary, we can replace it by a simple property ocm_classname. Of course, It is no necessary to map this property into a object attribute. It is still used internally by the ocm. By this way, the JCR repo has not be initialised correctly for OCM applications. WDYT ? I think that mixin node for ocm is right solution. You may just hide ocm:discriminator node type registration somewhere behind implementation to simplify OCM initialization. As I understand JCR specifications, purpose of mixin node type is to mark some node as capable of some extra functionality. That's exactly what OCM does. It adds some functionality to node, e.g. ability to be mapped to some class and object tree. Does not matter that you can create any property for any node. It will be just additional propery which may be misused. OCM is not mandatory part of JSR-283, even not mentioned there so... you are who makes the fashion :) -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
Re: [OCM] The ocm:discriminator
Thursday 07 February 2008 18:23:00 Christophe Lombart написав: That means the ObjectContentManager can be used only with Jackrabbit because node type registration is not standard. Not exactly. See JSR-283 ch. 6.10 and Appendix B. This is optional features for Level 2. Well, code may check this feature as specified in p. 6.10 and register new minxin type if it is possible. If repository can not register node types, your code may just add needed properties. And yes, CND is standard, not XML you currently use. Anyway, it's your code and you are decision maker. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
Re: Content Object Mapping - jcrom.org
Tuesday 05 February 2008 14:12:03 Alexandru Popescu ☀ написав: [skip] I do believe that this initiatives are helpful for the JCR community, but I would encourage people to check how much is possible to be done in the JPA direction. [skip] Sounds good again but: 1) Current ocm in jackrabbit source tree does not have anything in common with JPA annotation and/or ideology 2) JPA is based on relational approach and does not work properly with tree-like structures we use often with JCR 3) JPA is monstrous as current jackrabbit OCM is. 4) Where is effort mentioned above to join? Where is published source to look at? I checked jcrom and created nodes in 5 minutes. Current OCM took much much more time to go trough broken docs, complicated tests and hanging ends... So my opinion is: Simple and quick OCM like jcrom.org is just great solution. If some standard-addicted company wants to implement JPA on top JCR - that's good. If current official OCM is more flexible and powerfull - that's good too, but I need working OCM now and can't wait new implementations and neverending doc fixings. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
Re: Content Object Mapping - jcrom.org
Tuesday 05 February 2008 19:24:16 Alexandru Popescu ☀ написав:
Oops... it looks like I've left something unfinished...
On Feb 5, 2008 7:21 PM, Alexandru Popescu ☀
[EMAIL PROTECTED] wrote:
(to Alex Lukin):
2) JPA is based on relational approach and does not work properly with
tree-like structures we use often with JCR
That's partly correct. Indeed the theory of relational storage and
tree-based storage are radically different.
However, I do believe that part of the JPA annotations and moreover
API can be applied to any Object to X mapping solutions. And as I
said: it doesn't need to be 100% pure JPA ;-).
Well, may be. But JPA is not ideal solution for java persistance. It does not
handle right things like this:
class MyNode {
ListMyNode subNodes;
}
The nature of JCR is tree. The naure of tree processing is recursion.
JPA does not have any word about it. It has a lot of words about relational
stuff instead.
So use of JPA with JCR may be very misleading.
--
SY, Alex Lukin
RIPE NIC HDL: LEXA1-RIPE
Re: Content Object Mapping - jcrom.org
Tuesday 05 February 2008 20:53:46 Christophe Lombart написав: [skip] Alex, Jackrabbit OCM is also supporting the annotation like JCROM since a long time. XML support is not mandatory. Christophe, I know because I already use it. It works somehow for me and I prefer official things even when other project looks slightly better. I speak about hanging ends like: 1) namespace registration, additional node types registration etc that ought to be hidden from me somewhere inside of OCM init code. 2) lack of easy quick start example. That one on the web is just misleading and it's much better to replace it with just one line: Dig into spources, don't bother reading docs! Cutting example from tests is not trivial because of 1) Concerning JPA, we can make a small study to check if JPA is really a good solution for a JCR backend ... if someone have time :-) Pease do it after examples and docs :) BTW, writing examples makes one to finally understand what a beast was created and how to eat it right way! :) Speacking about missing features in current OCM that can be inspired by JPA ... well, finders. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
Re: Content Object Mapping - jcrom.org
Tuesday 05 February 2008 22:50:14 Christophe Lombart написав: [skip] I know I have the first (and very small) tutorial. I plan to publish it this week but I need more time due to my daily activities :-) Jackrabbit OCM will be more adopted if we find more contributors. They are still many thinks to do and making the doc takes time. So, if you have time , you are welcome I sent quick and dirty code to users@ list. If you wish you can give me write right on wiki and I'll publish my own examples. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
[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.
Re: Why there's no jcr-1.0.jar in 1.4 war dist?
Dear Jukka! Hi, On Feb 1, 2008 7:56 AM, Thomas Mueller [EMAIL PROTECTED] wrote: What about a 'standalone' download of Jackrabbit that includes Jetty? That would be nice, and also well in line with the embedded-shared-standalone deployment scenarios. I think that it is not a big deal to do such quick start bundles for deployment models 1,2,3. It will be good for developers. I spent 2 days with right model 2 setup (may be I'm so stupid, who knows :) and I think a lot of people who did not get it working in couple of hours just spit on the flor and gone away. One of the key reasons for not doing that so far is that we don't yet have production-ready JCR remoting options that would perform really well. JCR-RMI is stable and feature-rich but not very fast, and WebDAV remoting is still in the sandbox. You'll never get it right without users' loopbak. That's catch 22. But perhaps we should just do this, and let the performance issues sort themselves out. It's better to let features drive improvements and bug fixes than vice versa. You must. No perhaps :) If I where not interested very much in the technology academicaly, I'd never use it, belive me. I think taht jackrabbit is great and wish you good luck! But ... agh! You know! :) -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
[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.
Why there's no jcr-1.0.jar in 1.4 war dist?
JCR api jar is missing in war distro of 1.4 Looks strange and causes problems for new users. Is sere some impossible stupid copyright reason or it is just distribution bug? -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
Website OCM docs, page missing.
Hi, all! Please, webmasters! Check this page: http://jackrabbit.apache.org/ocm/api/basic-operations.html First link to very interesting part of docs points to missing page: http://jackrabbit.apache.org/ocm/engine-setup.html -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
