[jira] Commented: (JCR-1852) session.exportDocumentView() does not work with jaxb 2.1.x UnmarshallerHandler

2008-11-18 Thread Alex Lukin (JIRA)

[ 
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

2008-11-18 Thread Alex Lukin (JIRA)

[ 
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

2008-11-13 Thread Alex Lukin (JIRA)

[ 
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

2008-11-12 Thread Alex Lukin (JIRA)
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

2008-03-14 Thread Alex Lukin (JIRA)

[ 
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

2008-03-12 Thread Alex Lukin (JIRA)
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

2008-03-12 Thread Alex Lukin (JIRA)

 [ 
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

2008-02-21 Thread Alex Lukin (JIRA)
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

2008-02-08 Thread Alex Lukin (JIRA)

[ 
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

2008-02-08 Thread Alex Lukin (JIRA)

[ 
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

2008-02-01 Thread Alex Lukin (JIRA)
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

2008-01-31 Thread Alex Lukin (JIRA)
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.