[jira] Updated: (JCR-1291) Missing class JNDIDatabaseJournal
[ https://issues.apache.org/jira/browse/JCR-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guido Jäkel updated JCR-1291: - Attachment: Jäkel, Guido.vcf Dear Jukka, thank you for your quick reaction. Yes, no problem to choose the appropriate header because we intend to spread it to the community. My co-worker's did it within a quater of an hour and may (automatically) include our standart header without further considerations. Unfortunately, even using v1.4-rc1, our main (blocking) issue haven't gone: After a breakdown of the underying database connection (due to an idle timeout or a failure) the repository is unusable because it still fails to re-establish the database connection layer. I'll rescan the project jira for this an may open an issue ... sincerely yours Guido - 20080109-080323.749 WARN [ajp-8009-1] [] [DatabasePersistenceManager] execute failed, about to reconnect... 20080109-080333.786 ERROR [ajp-8009-1] [] [DatabasePersistenceManager] failed to re-establish connection javax.naming.NameNotFoundException: Name jdbc is not bound in this Context at org.apache.naming.NamingContext.lookup(NamingContext.java:770) at org.apache.naming.NamingContext.lookup(NamingContext.java:153) at org.apache.naming.SelectorContext.lookup(SelectorContext.java:137) at javax.naming.InitialContext.lookup(InitialContext.java:351) at org.apache.jackrabbit.core.persistence.db.JNDIDatabasePersistenceManager.getConnection(JNDIDatabasePersistenceManager.java:76) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.initConnection(DatabasePersistenceManager.java:744) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.reestablishConnection(DatabasePersistenceManager.java:823) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.executeStmt(DatabasePersistenceManager.java:869) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.exists(DatabasePersistenceManager.java:661) at org.apache.jackrabbit.core.state.SharedItemStateManager.hasNonVirtualItemState(SharedItemStateManager.java:1108) at org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(SharedItemStateManager.java:286) at org.apache.jackrabbit.core.state.LocalItemStateManager.hasItemState(LocalItemStateManager.java:178) at org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAItemStateManager.java:252) at org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:174) at org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.java:564) at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:395) at org.apache.jackrabbit.core.NodeImpl.internalAddChildNode(NodeImpl.java:770) at org.apache.jackrabbit.core.NodeImpl.internalAddNode(NodeImpl.java:718) at org.apache.jackrabbit.core.NodeImpl.internalAddNode(NodeImpl.java:665) at org.apache.jackrabbit.core.NodeImpl.addNode(NodeImpl.java:1987) at de.dNb.importService.packageManager.jcr.JcrPackageManager.newPackage(JcrPackageManager.java:85) -- Dr. Guido Jäkel Deutsche Nationalbibliothek IT SG 2.2 (Infrastruktur Unix) Adickesallee 1 60322 Frankfurt am Main Tel. +49-69-1525-1750 Fax +49-69-1525-1799 mailto:[EMAIL PROTECTED] http://www.d-nb.de > Missing class JNDIDatabaseJournal > - > > Key: JCR-1291 > URL: https://issues.apache.org/jira/browse/JCR-1291 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Guido Jäkel >Assignee: Jukka Zitting > Fix For: 1.4 > > Attachments: JNDIDatabaseJournal.java, Jäkel, Guido.vcf > > > We're dealing to set up a clustered repository and run into some issues and > missing features stated to be fixed in the upcoming v1.4. But while scanning > the sources of the v1.4-rc1, i still can't find the class > JNDIDatabaseJournal (org.apache.jackrabbit.core.journal.JNDIDatabaseJournal) > as a silbing to the classes > JNDIDatabaseFileSystem > (org.apache.jackrabbit.core.fs.db.JNDIDatabaseFileSystem) > and > JNDIDatabasePersistenceManager > (org.apache.jackrabbit.core.persistence.db.JNDIDatabasePersistenceManager) > The missing one you'll need to configure all parts of a repository handeled > in an abstract way by (e.g one common) JNDI database resource. From the > shortness and simplicity of the source code of the other ones, i think adding > this missing feature takes just about an hour. > Thank you for support -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1291) Missing class JNDIDatabaseJournal
[ https://issues.apache.org/jira/browse/JCR-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guido Jäkel updated JCR-1291: - Attachment: (was: Jäkel, Guido.vcf) > Missing class JNDIDatabaseJournal > - > > Key: JCR-1291 > URL: https://issues.apache.org/jira/browse/JCR-1291 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Guido Jäkel >Assignee: Jukka Zitting > Fix For: 1.4 > > Attachments: JNDIDatabaseJournal.java > > > We're dealing to set up a clustered repository and run into some issues and > missing features stated to be fixed in the upcoming v1.4. But while scanning > the sources of the v1.4-rc1, i still can't find the class > JNDIDatabaseJournal (org.apache.jackrabbit.core.journal.JNDIDatabaseJournal) > as a silbing to the classes > JNDIDatabaseFileSystem > (org.apache.jackrabbit.core.fs.db.JNDIDatabaseFileSystem) > and > JNDIDatabasePersistenceManager > (org.apache.jackrabbit.core.persistence.db.JNDIDatabasePersistenceManager) > The missing one you'll need to configure all parts of a repository handeled > in an abstract way by (e.g one common) JNDI database resource. From the > shortness and simplicity of the source code of the other ones, i think adding > this missing feature takes just about an hour. > Thank you for support -- 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-1291) Missing class JNDIDatabaseJournal
[ https://issues.apache.org/jira/browse/JCR-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557177#action_12557177 ] gjaekel edited comment on JCR-1291 at 1/9/08 12:21 AM: --- Dear Jukka, thank you for your quick reaction. Yes, no problem to choose the appropriate header because we intend to spread it to the community. My co-worker's did it within a quater of an hour and may (automatically) include our standart header without further considerations. Unfortunately, even using v1.4-rc1, our main (blocking) issue haven't gone: After a breakdown of the underying database connection (due to an idle timeout or a failure) the repository is unusable because it still fails to re-establish the database connection layer. I'll rescan the project jira for this an may open an issue ... sincerely yours Guido was (Author: gjaekel): Dear Jukka, > Missing class JNDIDatabaseJournal > - > > Key: JCR-1291 > URL: https://issues.apache.org/jira/browse/JCR-1291 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Guido Jäkel >Assignee: Jukka Zitting > Fix For: 1.4 > > Attachments: JNDIDatabaseJournal.java > > > We're dealing to set up a clustered repository and run into some issues and > missing features stated to be fixed in the upcoming v1.4. But while scanning > the sources of the v1.4-rc1, i still can't find the class > JNDIDatabaseJournal (org.apache.jackrabbit.core.journal.JNDIDatabaseJournal) > as a silbing to the classes > JNDIDatabaseFileSystem > (org.apache.jackrabbit.core.fs.db.JNDIDatabaseFileSystem) > and > JNDIDatabasePersistenceManager > (org.apache.jackrabbit.core.persistence.db.JNDIDatabasePersistenceManager) > The missing one you'll need to configure all parts of a repository handeled > in an abstract way by (e.g one common) JNDI database resource. From the > shortness and simplicity of the source code of the other ones, i think adding > this missing feature takes just about an hour. > Thank you for support -- 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-1291) Missing class JNDIDatabaseJournal
[ https://issues.apache.org/jira/browse/JCR-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557177#action_12557177 ] gjaekel edited comment on JCR-1291 at 1/9/08 12:21 AM: --- Dear Jukka, was (Author: gjaekel): Dear Jukka, thank you for your quick reaction. Yes, no problem to choose the appropriate header because we intend to spread it to the community. My co-worker's did it within a quater of an hour and may (automatically) include our standart header without further considerations. Unfortunately, even using v1.4-rc1, our main (blocking) issue haven't gone: After a breakdown of the underying database connection (due to an idle timeout or a failure) the repository is unusable because it still fails to re-establish the database connection layer. I'll rescan the project jira for this an may open an issue ... sincerely yours Guido - 20080109-080323.749 WARN [ajp-8009-1] [] [DatabasePersistenceManager] execute failed, about to reconnect... 20080109-080333.786 ERROR [ajp-8009-1] [] [DatabasePersistenceManager] failed to re-establish connection javax.naming.NameNotFoundException: Name jdbc is not bound in this Context at org.apache.naming.NamingContext.lookup(NamingContext.java:770) at org.apache.naming.NamingContext.lookup(NamingContext.java:153) at org.apache.naming.SelectorContext.lookup(SelectorContext.java:137) at javax.naming.InitialContext.lookup(InitialContext.java:351) at org.apache.jackrabbit.core.persistence.db.JNDIDatabasePersistenceManager.getConnection(JNDIDatabasePersistenceManager.java:76) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.initConnection(DatabasePersistenceManager.java:744) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.reestablishConnection(DatabasePersistenceManager.java:823) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.executeStmt(DatabasePersistenceManager.java:869) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.exists(DatabasePersistenceManager.java:661) at org.apache.jackrabbit.core.state.SharedItemStateManager.hasNonVirtualItemState(SharedItemStateManager.java:1108) at org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(SharedItemStateManager.java:286) at org.apache.jackrabbit.core.state.LocalItemStateManager.hasItemState(LocalItemStateManager.java:178) at org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAItemStateManager.java:252) at org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:174) at org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.java:564) at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:395) at org.apache.jackrabbit.core.NodeImpl.internalAddChildNode(NodeImpl.java:770) at org.apache.jackrabbit.core.NodeImpl.internalAddNode(NodeImpl.java:718) at org.apache.jackrabbit.core.NodeImpl.internalAddNode(NodeImpl.java:665) at org.apache.jackrabbit.core.NodeImpl.addNode(NodeImpl.java:1987) at de.dNb.importService.packageManager.jcr.JcrPackageManager.newPackage(JcrPackageManager.java:85) -- Dr. Guido Jäkel Deutsche Nationalbibliothek IT SG 2.2 (Infrastruktur Unix) Adickesallee 1 60322 Frankfurt am Main Tel. +49-69-1525-1750 Fax +49-69-1525-1799 mailto:[EMAIL PROTECTED] http://www.d-nb.de > Missing class JNDIDatabaseJournal > - > > Key: JCR-1291 > URL: https://issues.apache.org/jira/browse/JCR-1291 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Guido Jäkel >Assignee: Jukka Zitting > Fix For: 1.4 > > Attachments: JNDIDatabaseJournal.java > > > We're dealing to set up a clustered repository and run into some issues and > missing features stated to be fixed in the upcoming v1.4. But while scanning > the sources of the v1.4-rc1, i still can't find the class > JNDIDatabaseJournal (org.apache.jackrabbit.core.journal.JNDIDatabaseJournal) > as a silbing to the classes > JNDIDatabaseFileSystem > (org.apache.jackrabbit.core.fs.db.JNDIDatabaseFileSystem) > and > JNDIDatabasePersistenceManager > (org.apache.jackrabbit.core.persistence.db.JNDIDatabasePersistenceManager) > The missing one you'll need to configure all parts of a repository handeled > in an abstract way by (e.g one common) JNDI database resource. From the > shortness and simplicity of the source code of the other ones, i think adding > th
Re: jcr2spi spi2dav Sending large data, WorkspaceManager forgets exception
Hi, Well I had to increase maximum heap size for both client and tomcat server in order to be able to send 20mb binary property, and it was damn slow. I think most of the problem was by this base64 conversion. That is not good of course and I have to sind a solution pretty soon. When I use normal webdav interface (/repository/default/ instead of /server) and upload large file with traditional webdav client (e.g. bitkinex or cadaver) it is pretty fast and I don't have to increase maximum heap. So maybe one quick fix would be to first send the data traditional way and then modify the node with the help of spi2dav. Maybe this is also one possibility how to cope with it generally. Best, Jozef On 1/7/08, Angela Schreiber <[EMAIL PROTECTED]> wrote: > Thomas Mueller wrote: > > Hi, > > > >> a possible way improve this would be to make usage of > >> the global data store (JCR-926) > > > > That would be a solution. The idea is to avoid temporary copies of the > > data, and persist large objects as early as possible. I'm not sure if > > the data store should be used in the Jackrabbit SPI client > > the data store would be on the server. but i would introduce > means to be able have the binary QValue only 'contain' the > uri (or some other sort of identifier) and maybe the length. > the uri would be resolved only if the stream is obtained from > the value... something like that. > > and basically the object could be sent to the server upon > creating the initial qvalue already... what would be needed > was a separate qvaluefactory implementation and some extensions > to the jackrabbit-webapp that would allow to read/write the binary > objects irrespective of their jcr property. > that's what i meant my making usage of the global data store. > > angela >
[jira] Closed: (JCR-1259) Utility code for filtering and packaging trees
[ https://issues.apache.org/jira/browse/JCR-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed JCR-1259. - Looks good - thanks! > Utility code for filtering and packaging trees > -- > > Key: JCR-1259 > URL: https://issues.apache.org/jira/browse/JCR-1259 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-jcr-commons >Reporter: Carsten Ziegeler >Assignee: Jukka Zitting > Fix For: 1.4 > > Attachments: jcr-commons-filtering.zip, jcr-commons-filtering2.zip, > patch.txt > > > The attached zip contains new utility code for filtering and packaging trees > in the repository. > A tree can be traversed by the provided tree walker. During the traversal > configurable filters can be applied. The filters have influence on the > traversal, like skipping nodes or properties. > Included filters test the node name, node type etc. Custom filters are > possible as well. > A tree walker notifies a tree walker listener (interface) whenever it > traverses an item. > The second utility code is able to package a whole tree (through a > description) and export this in some way - the exporter is an interface and > could e.g. be an exporter serializing the tree into a zip archiv etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
OCM: Limitation with Path?
Hi. I am trying to use OCM in a project where the types of data to be stored in the repository are built with XMLBeans. This implies not having a "path" property in these classes, and sometimes not even any kind of String property to use as the path. At first I thought about wrapping these classes into another class that did have a path variable declared, but it finally came down to the same problem. I'd like to know if I'm doing something wrong or if the classes to be stored in the repository are limited to those that from the beginning have a "path" variable. Thanks in advance. Sebastian Gomez.
[jira] Created: (JCR-1298) Wrong schemaObjectPrefix parameter in default repository.xml
Wrong schemaObjectPrefix parameter in default repository.xml
Key: JCR-1298
URL: https://issues.apache.org/jira/browse/JCR-1298
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 1.3.3, 1.3.1
Reporter: Marcel Reutegger
Priority: Minor
The object schema prefix is hard-coded in the default configuration file (I
think this taken from the jackrabbit-core.jar):
This is probably caused by JCR-945, though I've no idea why ${wsp.name} is
replaced with the name of the module...
I have marked this issue as minor because it still works with the
DerbyPersistenceManager. There are separate database instances for each
workspace, but it will become a problem if a data base persistence manager on a
dedicated server is used.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Apache Jackrabbit 1.4 release candidate 1
I've identified a couple of issues with the demo web application, which I'd like to fix for the 1.4 release: https://issues.apache.org/jira/browse/JCR-1298 https://issues.apache.org/jira/browse/JCR-1299 regards marcel
[jira] Created: (JCR-1299) Default configuration not suitable for demo web application
Default configuration not suitable for demo web application --- Key: JCR-1299 URL: https://issues.apache.org/jira/browse/JCR-1299 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webapp Reporter: Marcel Reutegger Priority: Minor The default configuration is not suitable for the demo application. There are no text extractors configured, which makes the populate and search demos useless. Proposed solution: create a new repository.xml in jackrabbit-webapp with text extractors configured. I know we should actually try to reduce the number of repository.xml files, but having one dedicated to jackrabbit-webapp seems reasonable, while we should try to achieve the same for the jackrabbit-core module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: jcr2spi spi2dav Sending large data
hi jozef Well I had to increase maximum heap size for both client and tomcat server in order to be able to send 20mb binary property, and it was damn slow. I think most of the problem was by this base64 conversion. probably the easiest (least effort) solution would be to have an alternative implementation for RepositoryService.addProperty and RepositoryService.setValue in spi2dav. an alternative to the global binary store (that consequently would allow to keep the 'ValueProperty' (that sends the value array in a webdavish xml-body) would be a straight forward PUT for single-valued properties. that could (no garantuee) already work on the server. for multi-value properties a multipart request could be used. but that would require some additions on the server. can you open an issue for that? regards angela
[jira] Commented: (JCR-1298) Wrong schemaObjectPrefix parameter in default repository.xml
[
https://issues.apache.org/jira/browse/JCR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557233#action_12557233
]
Marcel Reutegger commented on JCR-1298:
---
This seems to be related to http://jira.codehaus.org/browse/MRESOURCES-3. The
report is pretty confusing and the resolution does not say in what version the
fix is.
> Wrong schemaObjectPrefix parameter in default repository.xml
>
>
> Key: JCR-1298
> URL: https://issues.apache.org/jira/browse/JCR-1298
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.3.1, 1.3.3
>Reporter: Marcel Reutegger
>Priority: Minor
>
> The object schema prefix is hard-coded in the default configuration file (I
> think this taken from the jackrabbit-core.jar):
> class="org.apache.jackrabbit.core.persistence.bundle.DerbyPersistenceManager">
>
>
>
> This is probably caused by JCR-945, though I've no idea why ${wsp.name} is
> replaced with the name of the module...
> I have marked this issue as minor because it still works with the
> DerbyPersistenceManager. There are separate database instances for each
> workspace, but it will become a problem if a data base persistence manager on
> a dedicated server is used.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1298) Wrong schemaObjectPrefix parameter in default repository.xml
[
https://issues.apache.org/jira/browse/JCR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557234#action_12557234
]
Jukka Zitting commented on JCR-1298:
We should probably disable filtering for most parts of src/main/resources.
> Wrong schemaObjectPrefix parameter in default repository.xml
>
>
> Key: JCR-1298
> URL: https://issues.apache.org/jira/browse/JCR-1298
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.3.1, 1.3.3
>Reporter: Marcel Reutegger
>Priority: Minor
>
> The object schema prefix is hard-coded in the default configuration file (I
> think this taken from the jackrabbit-core.jar):
> class="org.apache.jackrabbit.core.persistence.bundle.DerbyPersistenceManager">
>
>
>
> This is probably caused by JCR-945, though I've no idea why ${wsp.name} is
> replaced with the name of the module...
> I have marked this issue as minor because it still works with the
> DerbyPersistenceManager. There are separate database instances for each
> workspace, but it will become a problem if a data base persistence manager on
> a dedicated server is used.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1299) Default configuration not suitable for demo web application
[ https://issues.apache.org/jira/browse/JCR-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1299: --- How about configuring the text extractors already in the repository.xml in jackrabbit-core? We already have a compile-scoped dependency to text-extractors in core, so it's reasonable to expect that the classes are available in normal deployments. > Default configuration not suitable for demo web application > --- > > Key: JCR-1299 > URL: https://issues.apache.org/jira/browse/JCR-1299 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-webapp >Reporter: Marcel Reutegger >Priority: Minor > > The default configuration is not suitable for the demo application. There are > no text extractors configured, which makes the populate and search demos > useless. > Proposed solution: create a new repository.xml in jackrabbit-webapp with text > extractors configured. > I know we should actually try to reduce the number of repository.xml files, > but having one dedicated to jackrabbit-webapp seems reasonable, while we > should try to achieve the same for the jackrabbit-core module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1298) Wrong schemaObjectPrefix parameter in default repository.xml
[
https://issues.apache.org/jira/browse/JCR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557236#action_12557236
]
Marcel Reutegger commented on JCR-1298:
---
The only workaround I see is:
- move the repository.properties to a separate resources-filtered folder
- change the pom.xml
Index: pom.xml
===
--- pom.xml (revision 610328)
+++ pom.xml (working copy)
@@ -230,6 +230,9 @@
src/main/resources
+
+
+src/main/resources-filtered
true
Does anyone have a better idea?
> Wrong schemaObjectPrefix parameter in default repository.xml
>
>
> Key: JCR-1298
> URL: https://issues.apache.org/jira/browse/JCR-1298
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.3.1, 1.3.3
>Reporter: Marcel Reutegger
>Priority: Minor
>
> The object schema prefix is hard-coded in the default configuration file (I
> think this taken from the jackrabbit-core.jar):
> class="org.apache.jackrabbit.core.persistence.bundle.DerbyPersistenceManager">
>
>
>
> This is probably caused by JCR-945, though I've no idea why ${wsp.name} is
> replaced with the name of the module...
> I have marked this issue as minor because it still works with the
> DerbyPersistenceManager. There are separate database instances for each
> workspace, but it will become a problem if a data base persistence manager on
> a dedicated server is used.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Apache Jackrabbit 1.4 release candidate 1
Hi, On Jan 9, 2008 12:23 PM, Marcel Reutegger <[EMAIL PROTECTED]> wrote: > I've identified a couple of issues with the demo web application, which I'd > like > to fix for the 1.4 release: > > https://issues.apache.org/jira/browse/JCR-1298 > https://issues.apache.org/jira/browse/JCR-1299 Good points, see my comments in the issues. Will you be fixing these, or should I? I can take care of merging the fixes to the 1.4 branch. BR, Jukka Zitting
[jira] Commented: (JCR-1298) Wrong schemaObjectPrefix parameter in default repository.xml
[
https://issues.apache.org/jira/browse/JCR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557237#action_12557237
]
Marcel Reutegger commented on JCR-1298:
---
Jukka wrote:
> We should probably disable filtering for most parts of src/main/resources.
to my knowledge you can not selectively filter, except when using separate
resource directories. see previous comment.
> Wrong schemaObjectPrefix parameter in default repository.xml
>
>
> Key: JCR-1298
> URL: https://issues.apache.org/jira/browse/JCR-1298
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.3.1, 1.3.3
>Reporter: Marcel Reutegger
>Priority: Minor
>
> The object schema prefix is hard-coded in the default configuration file (I
> think this taken from the jackrabbit-core.jar):
> class="org.apache.jackrabbit.core.persistence.bundle.DerbyPersistenceManager">
>
>
>
> This is probably caused by JCR-945, though I've no idea why ${wsp.name} is
> replaced with the name of the module...
> I have marked this issue as minor because it still works with the
> DerbyPersistenceManager. There are separate database instances for each
> workspace, but it will become a problem if a data base persistence manager on
> a dedicated server is used.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1299) Default configuration not suitable for demo web application
[ https://issues.apache.org/jira/browse/JCR-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557238#action_12557238 ] Marcel Reutegger commented on JCR-1299: --- Hmm, there are also other features that I would like to enable for the demo web application: excerpts and spell checking. But you are right, why shouldn't we enable those features per default? I'll create a patch. > Default configuration not suitable for demo web application > --- > > Key: JCR-1299 > URL: https://issues.apache.org/jira/browse/JCR-1299 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-webapp >Reporter: Marcel Reutegger >Priority: Minor > > The default configuration is not suitable for the demo application. There are > no text extractors configured, which makes the populate and search demos > useless. > Proposed solution: create a new repository.xml in jackrabbit-webapp with text > extractors configured. > I know we should actually try to reduce the number of repository.xml files, > but having one dedicated to jackrabbit-webapp seems reasonable, while we > should try to achieve the same for the jackrabbit-core module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: jcr2spi spi2dav Sending large data
Hi Angela, On 1/9/08, Angela Schreiber <[EMAIL PROTECTED]> wrote: > > can you open an issue for that? > Done, http://issues.apache.org/jira/browse/JCR-1300 Best, Jozef
[jira] Created: (JCR-1300) spi2dav Improve performance for large binary properties
spi2dav Improve performance for large binary properties --- Key: JCR-1300 URL: https://issues.apache.org/jira/browse/JCR-1300 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-spi Reporter: Jozef Wagner Sending large binary properties over spi2dav is slow and requires a lot of heap space in both client and server. One problematic part is base64 conversion of the property value. On the contrary, using 'normal' webdav interface (/repository/default/ instead of /server) for uploading a file (through traditional webdav client) it is pretty fast and don't have such impact on heap space. Some suggestions from the previous discussion: - avoid temporary copies of the data, and persist large objects as early as possible. - transfer large objects in blocks from the Jackrabbit SPI client to the server (and back). - make usage of the global data store (JCR-926). - straight forward PUT for single-valued properties Link to discussion: http://www.mail-archive.com/dev@jackrabbit.apache.org/msg09481.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1298) Wrong schemaObjectPrefix parameter in default repository.xml
[
https://issues.apache.org/jira/browse/JCR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557249#action_12557249
]
Jukka Zitting commented on JCR-1298:
The resources-filtered idea seems OK to me.
> Wrong schemaObjectPrefix parameter in default repository.xml
>
>
> Key: JCR-1298
> URL: https://issues.apache.org/jira/browse/JCR-1298
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.3.1, 1.3.3
>Reporter: Marcel Reutegger
>Priority: Minor
>
> The object schema prefix is hard-coded in the default configuration file (I
> think this taken from the jackrabbit-core.jar):
> class="org.apache.jackrabbit.core.persistence.bundle.DerbyPersistenceManager">
>
>
>
> This is probably caused by JCR-945, though I've no idea why ${wsp.name} is
> replaced with the name of the module...
> I have marked this issue as minor because it still works with the
> DerbyPersistenceManager. There are separate database instances for each
> workspace, but it will become a problem if a data base persistence manager on
> a dedicated server is used.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1299) Default configuration not suitable for demo web application
[ https://issues.apache.org/jira/browse/JCR-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated JCR-1299: -- Attachment: JCR-1299.patch Configuration patch > Default configuration not suitable for demo web application > --- > > Key: JCR-1299 > URL: https://issues.apache.org/jira/browse/JCR-1299 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-webapp >Reporter: Marcel Reutegger >Priority: Minor > Attachments: JCR-1299.patch > > > The default configuration is not suitable for the demo application. There are > no text extractors configured, which makes the populate and search demos > useless. > Proposed solution: create a new repository.xml in jackrabbit-webapp with text > extractors configured. > I know we should actually try to reduce the number of repository.xml files, > but having one dedicated to jackrabbit-webapp seems reasonable, while we > should try to achieve the same for the jackrabbit-core module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Apache Jackrabbit 1.4 release candidate 1
Jukka Zitting wrote: Will you be fixing these, or should I? I can take care of merging the fixes to the 1.4 branch. I'll fix them and also merge the changes to the 1.4 branch. regards marcel
RE: Use of "not" in xpath queries (1.4 snapshot / trunk)
Hello,
I am crossposting to dev list because it is a development issue we might
want to discuss for the 1.4 release (because behavior of a query changed
a little)
> /jcr:root//element(*, MyNodeType)[not(@propertyA)]
>
> After some testing, it seems that where propertyA is defined
> on MyNodeType (in the .cnd file), then this query will now
> not match nodes that do not have a value for propertyA. Where
> propertyA is not a defined property for MyNodeType, nodes
> will be matched. Previously (in 1.3.3), nodes that had the
> property defined but did not have a value for that property
> would be returned by the query (this is what I had expected
> from the jsr-170 spec). Thanks in advance for any help,
So for 1.3.3 IIUC, when you queried for : give me all nodes where
property X does not exist, it would return documents which have the
property X, but where it is empty? IMO, it is not logical, then again,
unfortunate that the behavior would have changed. We did change the way
this query is executed (see JCR-1064).
I see where the problem arises from, but I think it did not work
correctly before (though others might be better in judging this. I
think, it did not work correctly in 1.3.3, and you made use of something
which is not logical (returning nodes which have the property, where you
say that they shouldn't have it))
Which part of the jsr-170 spec are you referring to by the way?
Anyway, we changed the MatchAllQuery into a query that test for the
existence of a property in SET_PROPERTIES. Since your property is
present, with the not(@prop) it will not return your document.
In 1.3.3, we used the MatchAllScorer for this, where the query term was
computed in
String namedValue = FieldNames.createNamedValue(field, "");
TermEnum terms = reader.terms(new Term(FieldNames.PROPERTIES,
namedValue));
and in FieldNames :
public static String createNamedValue(String fieldName, String value) {
return fieldName + '\u' + value;
}
I think, because of this '\u', you did not get a match for an empty
property before, where you do get a match now.
Anyway, IMO, it now works correct. WDOT?
-Ard
>
> Dean.
>
[jira] Resolved: (JCR-1298) Wrong schemaObjectPrefix parameter in default repository.xml
[
https://issues.apache.org/jira/browse/JCR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved JCR-1298.
---
Resolution: Fixed
Fix Version/s: 1.4
Fixed in trunk (610372) and 1.4 branch (610377).
> Wrong schemaObjectPrefix parameter in default repository.xml
>
>
> Key: JCR-1298
> URL: https://issues.apache.org/jira/browse/JCR-1298
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.3.1, 1.3.3
>Reporter: Marcel Reutegger
>Priority: Minor
> Fix For: 1.4
>
>
> The object schema prefix is hard-coded in the default configuration file (I
> think this taken from the jackrabbit-core.jar):
> class="org.apache.jackrabbit.core.persistence.bundle.DerbyPersistenceManager">
>
>
>
> This is probably caused by JCR-945, though I've no idea why ${wsp.name} is
> replaced with the name of the module...
> I have marked this issue as minor because it still works with the
> DerbyPersistenceManager. There are separate database instances for each
> workspace, but it will become a problem if a data base persistence manager on
> a dedicated server is used.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Apache Jackrabbit 1.4 release candidate 1
Hi, On Jan 9, 2008 3:12 PM, Marcel Reutegger <[EMAIL PROTECTED]> wrote: > Jukka Zitting wrote: > > Will you be fixing these, or should I? I can take care of merging the > > fixes to the 1.4 branch. > > I'll fix them and also merge the changes to the 1.4 branch. Excellent, thanks! BR, Jukka Zitting
[jira] Resolved: (JCR-1299) Default configuration not suitable for demo web application
[ https://issues.apache.org/jira/browse/JCR-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-1299. --- Resolution: Fixed Fix Version/s: 1.4 Committed patch in 1.4 branch (610382) and trunk (610383). > Default configuration not suitable for demo web application > --- > > Key: JCR-1299 > URL: https://issues.apache.org/jira/browse/JCR-1299 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-webapp >Reporter: Marcel Reutegger >Priority: Minor > Fix For: 1.4 > > Attachments: JCR-1299.patch > > > The default configuration is not suitable for the demo application. There are > no text extractors configured, which makes the populate and search demos > useless. > Proposed solution: create a new repository.xml in jackrabbit-webapp with text > extractors configured. > I know we should actually try to reduce the number of repository.xml files, > but having one dedicated to jackrabbit-webapp seems reasonable, while we > should try to achieve the same for the jackrabbit-core module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Regarding IndexingConfiguration
Hi Ard, Ard Schrijvers wrote: Yesterday I tried to use http://jackrabbit.apache.org/dtd/indexing-configuration-1.0.dtd";> http://www.jcp.org/jcr/nt/1.0";> someProp and thought that this would mean that all properties would be nodescope indexed, except 'someProp'. Perhaps I am wrong about my expectation, but this index-rule results in that no property at all makes it to the nodescope index. AFAICS, there is no easy way to exclude one single property from the nodescope, without having to add *all* properties you do want in the nodescope. Is this behavior correct and intentional? yes, this is correct and intended. reason for this is, that I wanted people to explicitly declare what they want to index, instead of a default that includes everything (well, that actually is the default if there is *no* configuration at all ;) ). regards marcel
RE: Regarding IndexingConfiguration
Hi Marcel > > yes, this is correct and intended. > > reason for this is, that I wanted people to explicitly > declare what they want to index, instead of a default that > includes everything (well, that actually is the default if > there is *no* configuration at all ;) ). Ok. Not really a problem for me (would consider it a matter of taste anyway), but I just had this usecase which I could not accomplish with only configuring the indexing_configuration. I'll get around it. Thx for the explanation, Regards Ard > > regards > marcel >
[jira] Commented: (JCR-1293) ReorderReferenceableSNSTest failure
[ https://issues.apache.org/jira/browse/JCR-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557347#action_12557347 ] angela commented on JCR-1293: - i managed to get the ReorderReferenceableSNSTest.testRevertReorder failing. up to now i saw 2 variants of the reorder-tests failing (both due to additional child-nodes) and i don't know yet, whether they are related: a): the additional nodes had not uniqueID, means that they are not mix:referenceable in the underlying jackrabbit repository (which i verified looking at the jackrabbit-nodes directly). this is somehow unexpected sinde the tests only creates referenceable child nodes (at least it are intended to do so). the result in this situation is always: inconsistent state and the teardown fails with InvalidItemStateException. b) cleanUpTestRoot of the AbstractJCRTest is called twice both in the setup and in the teardown and it retrieves all child-nodes from the testRoot and removes them. i saw, that from time to time not all child-nodes get removed (i imagine due to the weak nature of the hierarchy)... in this case one test simple failed without causing inconsistencies for the subsequent tests. > ReorderReferenceableSNSTest failure > --- > > Key: JCR-1293 > URL: https://issues.apache.org/jira/browse/JCR-1293 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core, jackrabbit-jcr2spi >Affects Versions: 1.4 > Environment: Windows XP, Sun JDK 1.4.2_13 >Reporter: Thomas Mueller > > I have checked out the Jackrabbit 1.4 branch to a new directory, and called: > mvn clean install > The error is: > Building Jackrabbit JCR to SPI > task-segment: [clean, install] > - > ... > testRevertReorder(org.apache.jackrabbit.jcr2spi.ReorderReferenceableSNSTest) > junit.framework.AssertionFailedError: Reorder added a child node. >at junit.framework.Assert.fail(Assert.java:47) >at > org.apache.jackrabbit.jcr2spi.ReorderTest.testOrder(ReorderTest.java:90) >at > org.apache.jackrabbit.jcr2spi.ReorderTest.testRevertReorder(ReorderTest.java:122) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1301) Trouble undeploying jackrabbit-webapp from Tomcat
Trouble undeploying jackrabbit-webapp from Tomcat - Key: JCR-1301 URL: https://issues.apache.org/jira/browse/JCR-1301 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-webapp Environment: Windows Vista, Apache Tomcat 6.0.12, Sun Java 1.6.0_03 Reporter: Jukka Zitting When testing jackrabbit-webapp for the 1.4 release, I again came across this issue that I've occasionally seen also before, but never qualified enough for a bug report. The Jackrabbit webapp would deploy without problems, but when I undeploy the webapp Tomcat fails to remove the Derby jar in WEB-INF/lib (I have unpackWARs enabled). This causes problems especially when I have autoDeploy enabled, as Tomcat then deploys the skeleton webapp right after undeployment, and the only way to really get rid of the webapp is to shutdown Tomcat and to manually remove the webapp on the file system. I suspect that this problem is related to Derby jar being somehow referenced even after the webapp is undeployed, causing Windows to prevent the jar file from being removed. Unless someone has some bright idea on how to resolve this, I'll consider this a known issue in Jackrabbit 1.4. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1302) ArrayHits does not end properly when skipTo doesn't find document
[
https://issues.apache.org/jira/browse/JCR-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl reassigned JCR-1302:
Assignee: Christoph Kiehl
> ArrayHits does not end properly when skipTo doesn't find document
> -
>
> Key: JCR-1302
> URL: https://issues.apache.org/jira/browse/JCR-1302
> Project: Jackrabbit
> Issue Type: Bug
> Components: query
>Affects Versions: 1.4
>Reporter: Rob Owen
>Assignee: Christoph Kiehl
> Fix For: 1.4
>
>
> If skipTo(target) does not find a document that that has a higher value than
> the target, it falls out of the loop and calls next() possibly returning a
> previously found document. The patch makes sure that -1 is returned in this
> case, otherwise confusing results might occur.
> Index:
> src/main/java/org/apache/jackrabbit/core/query/lucene/hits/ArrayHits.java
> ===
> --- src/main/java/org/apache/jackrabbit/core/query/lucene/hits/ArrayHits.java
> (revision 608900)
> +++ src/main/java/org/apache/jackrabbit/core/query/lucene/hits/ArrayHits.java
> (working copy)
> @@ -87,9 +87,9 @@
> int nextDocValue = hits[i];
> if (nextDocValue >= target) {
> index = i;
> -break;
> +return next();
> }
> }
> -return next();
> +return -1;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1302) ArrayHits does not end properly when skipTo doesn't find document
ArrayHits does not end properly when skipTo doesn't find document
-
Key: JCR-1302
URL: https://issues.apache.org/jira/browse/JCR-1302
Project: Jackrabbit
Issue Type: Bug
Components: query
Affects Versions: 1.4
Reporter: Rob Owen
Fix For: 1.4
If skipTo(target) does not find a document that that has a higher value than
the target, it falls out of the loop and calls next() possibly returning a
previously found document. The patch makes sure that -1 is returned in this
case, otherwise confusing results might occur.
Index: src/main/java/org/apache/jackrabbit/core/query/lucene/hits/ArrayHits.java
===
--- src/main/java/org/apache/jackrabbit/core/query/lucene/hits/ArrayHits.java
(revision 608900)
+++ src/main/java/org/apache/jackrabbit/core/query/lucene/hits/ArrayHits.java
(working copy)
@@ -87,9 +87,9 @@
int nextDocValue = hits[i];
if (nextDocValue >= target) {
index = i;
-break;
+return next();
}
}
-return next();
+return -1;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1303) Missing derby dependency
Missing derby dependency Key: JCR-1303 URL: https://issues.apache.org/jira/browse/JCR-1303 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.4 Reporter: Christophe Lombart Priority: Blocker the derby dependency is missing in the OCM subproject. So, the unit tests cannot be executed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1303) Missing derby dependency
[ https://issues.apache.org/jira/browse/JCR-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1303. - Resolution: Fixed Fix Version/s: 1.5 Fixed in 1.5-snapshot. Do we have to fix it in the 1.4 branch ? > Missing derby dependency > > > Key: JCR-1303 > URL: https://issues.apache.org/jira/browse/JCR-1303 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-ocm >Affects Versions: 1.4 >Reporter: Christophe Lombart >Priority: Blocker > Fix For: 1.5 > > > the derby dependency is missing in the OCM subproject. So, the unit tests > cannot be executed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1303) Missing derby dependency
[ https://issues.apache.org/jira/browse/JCR-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557507#action_12557507 ] Jukka Zitting commented on JCR-1303: The unit tests ran just fine for me even before this change. Derby is a transitive dependency brought in by jackrabbit-core. > Missing derby dependency > > > Key: JCR-1303 > URL: https://issues.apache.org/jira/browse/JCR-1303 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-ocm >Affects Versions: 1.4 >Reporter: Christophe Lombart >Priority: Blocker > Fix For: 1.5 > > > the derby dependency is missing in the OCM subproject. So, the unit tests > cannot be executed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1303) Missing derby dependency
[ https://issues.apache.org/jira/browse/JCR-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557550#action_12557550 ] Christophe Lombart commented on JCR-1303: - Ha yes ! I'm just wondering why is not working on my machine. I'm going to check and remove my change. thanks > Missing derby dependency > > > Key: JCR-1303 > URL: https://issues.apache.org/jira/browse/JCR-1303 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-ocm >Affects Versions: 1.4 >Reporter: Christophe Lombart >Priority: Blocker > Fix For: 1.5 > > > the derby dependency is missing in the OCM subproject. So, the unit tests > cannot be executed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
