[jira] Commented: (JCR-1617) Remove collons-collections and slf4j-api dependencies from jcr-commons
[ https://issues.apache.org/jira/browse/JCR-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598580#action_12598580 ] Stefan Guggisberg commented on JCR-1617: +1 for the patch > Remove collons-collections and slf4j-api dependencies from jcr-commons > -- > > Key: JCR-1617 > URL: https://issues.apache.org/jira/browse/JCR-1617 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-jcr-commons >Reporter: Jukka Zitting >Assignee: Jukka Zitting > Fix For: 1.5 > > Attachments: JCR-1617.patch > > > As noted in JCR-1615 and discussed on the mailing list [1] it would be good > if jackrabbit-jcr-commons didn't come with extra dependencies beyond the > standard Java class libraries and the JCR API. > Currently jackrabbit-jcr-commons depends on both commons-collections and > slf4j-api, but both dependencies are relatively isolated and could be dropped > with relatively little effort. Both dependency changes may be backwards > incompatible with existing clients, but since the impact is reasonably small > and easy to resolve I'd be OK doing this in 1.5. > [1] http://markmail.org/message/724ruk4l7b5rjtan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1619) Update copyright years in READMEs
[ https://issues.apache.org/jira/browse/JCR-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-1619. Resolution: Fixed Fixed in revision 658575. PS. Should we be using "200x-2008" instead of just "2008"? > Update copyright years in READMEs > - > > Key: JCR-1619 > URL: https://issues.apache.org/jira/browse/JCR-1619 > Project: Jackrabbit > Issue Type: Improvement >Reporter: Jukka Zitting >Assignee: Jukka Zitting >Priority: Trivial > Fix For: 1.5 > > > The README.txt files of Jackrabbit components contain copyright lines like > this: > Collective work: Copyright 2007 The Apache Software Foundation. > The year should be updated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1557) Avoid exceptions during shutting repository down if several PMs/FSs use same DB
[ https://issues.apache.org/jira/browse/JCR-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated JCR-1557: --- Fix Version/s: core 1.4.4 > Avoid exceptions during shutting repository down if several PMs/FSs use same > DB > --- > > Key: JCR-1557 > URL: https://issues.apache.org/jira/browse/JCR-1557 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: core 1.4.2 > Environment: Apache Derby / 10.3.2.1 - (599110) >Reporter: Roman Puchkovskiy >Priority: Minor > Fix For: core 1.4.4 > > Attachments: repository.xml > > > According to docs and forum discussions, it's legal to use same DB for > different FileSystems/Persistence Managers. Such configurations seem to work > fine, but when repository is stopped, exceptions are produced like following: > SEVERE: Error while closing Version Manager. > java.sql.SQLNonTransientConnectionException: No current connection. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown > Source) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedConnection.checkIfClosed(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedConnection.getMetaData(Unknown > Source) > at > org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager.closeConnection(DerbyPersistenceManager.java:109) > at > org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.close(DatabasePersistenceManager.java:261) > at > org.apache.jackrabbit.core.version.VersionManagerImpl.close(VersionManagerImpl.java:201) > at > org.apache.jackrabbit.core.RepositoryImpl.doShutdown(RepositoryImpl.java:1000) > at > org.apache.jackrabbit.core.RepositoryImpl.shutdown(RepositoryImpl.java:948) > at > org.apache.jackrabbit.core.TransientRepository.stopRepository(TransientRepository.java:275) > at > org.apache.jackrabbit.core.TransientRepository.loggedOut(TransientRepository.java:427) > at > org.apache.jackrabbit.core.SessionImpl.notifyLoggedOut(SessionImpl.java:574) > at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1247) > at > org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:403) > at > com.blandware.tooling.jcrplugin.ExportMojo.execute(ExportMojo.java:81) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: java.sql.SQLException: No current connection. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) > at > org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown > Source) > ... 35 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1557) Avoid exceptions during shutting repository down if several PMs/FSs use same DB
[ https://issues.apache.org/jira/browse/JCR-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved JCR-1557. Resolution: Fixed fixed in r658583. > Avoid exceptions during shutting repository down if several PMs/FSs use same > DB > --- > > Key: JCR-1557 > URL: https://issues.apache.org/jira/browse/JCR-1557 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: core 1.4.2 > Environment: Apache Derby / 10.3.2.1 - (599110) >Reporter: Roman Puchkovskiy >Priority: Minor > Attachments: repository.xml > > > According to docs and forum discussions, it's legal to use same DB for > different FileSystems/Persistence Managers. Such configurations seem to work > fine, but when repository is stopped, exceptions are produced like following: > SEVERE: Error while closing Version Manager. > java.sql.SQLNonTransientConnectionException: No current connection. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown > Source) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedConnection.checkIfClosed(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedConnection.getMetaData(Unknown > Source) > at > org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager.closeConnection(DerbyPersistenceManager.java:109) > at > org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.close(DatabasePersistenceManager.java:261) > at > org.apache.jackrabbit.core.version.VersionManagerImpl.close(VersionManagerImpl.java:201) > at > org.apache.jackrabbit.core.RepositoryImpl.doShutdown(RepositoryImpl.java:1000) > at > org.apache.jackrabbit.core.RepositoryImpl.shutdown(RepositoryImpl.java:948) > at > org.apache.jackrabbit.core.TransientRepository.stopRepository(TransientRepository.java:275) > at > org.apache.jackrabbit.core.TransientRepository.loggedOut(TransientRepository.java:427) > at > org.apache.jackrabbit.core.SessionImpl.notifyLoggedOut(SessionImpl.java:574) > at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1247) > at > org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:403) > at > com.blandware.tooling.jcrplugin.ExportMojo.execute(ExportMojo.java:81) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: java.sql.SQLException: No current connection. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) > at > org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown > Source) > ... 35 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1310) Webdav: Drop xerces dependency
[ https://issues.apache.org/jira/browse/JCR-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela reassigned JCR-1310: --- Assignee: angela > Webdav: Drop xerces dependency > -- > > Key: JCR-1310 > URL: https://issues.apache.org/jira/browse/JCR-1310 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-webdav >Reporter: angela >Assignee: angela >Priority: Minor > Attachments: JCR-1261.drop-xerces.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1310) Webdav: Drop xerces dependency
[ https://issues.apache.org/jira/browse/JCR-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-1310: Attachment: JCR-1310.diff extended patch that moves the NamespaceFixingContentHandler from jcr2spi to the jackrabbit-jcr-commons project, adds a namespace aware transformer and uses that one for the xml serialization in the webdav project. i did the following tests: - run litmus on the dav server - run some read/write/search tests on a jcr2spi-spi2dav-jcrserver setup. and had the impression that it works... comments? anybody having time to do some more tests? angela > Webdav: Drop xerces dependency > -- > > Key: JCR-1310 > URL: https://issues.apache.org/jira/browse/JCR-1310 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-webdav >Reporter: angela >Assignee: angela >Priority: Minor > Attachments: JCR-1261.drop-xerces.patch, JCR-1310.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1310) Webdav: Drop xerces dependency
[ https://issues.apache.org/jira/browse/JCR-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598601#action_12598601 ] angela commented on JCR-1310: - i will leave this issue open for a couple of days giving everybody the change to test or take a look at it. unless objections are raised i would then commit the changes proposed beginning next week. angela > Webdav: Drop xerces dependency > -- > > Key: JCR-1310 > URL: https://issues.apache.org/jira/browse/JCR-1310 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-webdav >Reporter: angela >Assignee: angela >Priority: Minor > Attachments: JCR-1261.drop-xerces.patch, JCR-1310.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1620) Make the Analyzer configurable per node (or subtree)
[ https://issues.apache.org/jira/browse/JCR-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paco Avila updated JCR-1620: Description: Would be nice that Jackrabbit could index documents in several languages and use an specific Lucene Analizer for each one to get optimal quesy results. (was: Would be nice that Jackrabbit could index documents in several languages and use an specific Lucene Analizer for echar one to get optimal quesy results.) > Make the Analyzer configurable per node (or subtree) > > > Key: JCR-1620 > URL: https://issues.apache.org/jira/browse/JCR-1620 > Project: Jackrabbit > Issue Type: Improvement > Components: indexing >Reporter: Paco Avila > > Would be nice that Jackrabbit could index documents in several languages and > use an specific Lucene Analizer for each one to get optimal quesy results. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1557) Avoid exceptions during shutting repository down if several PMs/FSs use same DB
[ https://issues.apache.org/jira/browse/JCR-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1557: --- Fix Version/s: (was: core 1.4.4) core 1.4.5 Issue Type: Bug (was: Improvement) > Avoid exceptions during shutting repository down if several PMs/FSs use same > DB > --- > > Key: JCR-1557 > URL: https://issues.apache.org/jira/browse/JCR-1557 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: core 1.4.2 > Environment: Apache Derby / 10.3.2.1 - (599110) >Reporter: Roman Puchkovskiy >Priority: Minor > Fix For: core 1.4.5 > > Attachments: repository.xml > > > According to docs and forum discussions, it's legal to use same DB for > different FileSystems/Persistence Managers. Such configurations seem to work > fine, but when repository is stopped, exceptions are produced like following: > SEVERE: Error while closing Version Manager. > java.sql.SQLNonTransientConnectionException: No current connection. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown > Source) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedConnection.checkIfClosed(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedConnection.getMetaData(Unknown > Source) > at > org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager.closeConnection(DerbyPersistenceManager.java:109) > at > org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.close(DatabasePersistenceManager.java:261) > at > org.apache.jackrabbit.core.version.VersionManagerImpl.close(VersionManagerImpl.java:201) > at > org.apache.jackrabbit.core.RepositoryImpl.doShutdown(RepositoryImpl.java:1000) > at > org.apache.jackrabbit.core.RepositoryImpl.shutdown(RepositoryImpl.java:948) > at > org.apache.jackrabbit.core.TransientRepository.stopRepository(TransientRepository.java:275) > at > org.apache.jackrabbit.core.TransientRepository.loggedOut(TransientRepository.java:427) > at > org.apache.jackrabbit.core.SessionImpl.notifyLoggedOut(SessionImpl.java:574) > at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1247) > at > org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:403) > at > com.blandware.tooling.jcrplugin.ExportMojo.execute(ExportMojo.java:81) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: java.sql.SQLException: No current connection. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) > at > org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown > Source) > ... 35 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1620) Make the Analyzer configurable per node (or subtree)
Make the Analyzer configurable per node (or subtree) Key: JCR-1620 URL: https://issues.apache.org/jira/browse/JCR-1620 Project: Jackrabbit Issue Type: Improvement Components: indexing Reporter: Paco Avila Would be nice that Jackrabbit could index documents in several languages and use an specific Lucene Analizer for echar one to get optimal quesy results. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
ClusterNode and snapshot question.
I have a question about ClusterNode and the Journal. If I bring a new app server node into a Jackrabbit cluster, the journal gets replayed from scratch, this can take some time if the cluster has been running for some time. I would like to avoid this if possible. It would be nice to be able to snapshot the local state of an app server, and use that to a) seed new app servers as they joined the cluster b) truncate the redo log to prevent eternal growth. Is this the right way to achieve a fast start of a new app server in the cluster ? Is it necessary to run the journal from scratch (I assume it is due to the indexing operations)? Has anyone already looked at this ? I searched the lists but I couldn't find anything. Thanks Ian
[jira] Updated: (JCR-1617) Remove commons-collections and slf4j-api dependencies from jcr-commons
[ https://issues.apache.org/jira/browse/JCR-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1617: --- Summary: Remove commons-collections and slf4j-api dependencies from jcr-commons (was: Remove collons-collections and slf4j-api dependencies from jcr-commons) > Remove commons-collections and slf4j-api dependencies from jcr-commons > -- > > Key: JCR-1617 > URL: https://issues.apache.org/jira/browse/JCR-1617 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-jcr-commons >Reporter: Jukka Zitting >Assignee: Jukka Zitting > Fix For: 1.5 > > Attachments: JCR-1617.patch > > > As noted in JCR-1615 and discussed on the mailing list [1] it would be good > if jackrabbit-jcr-commons didn't come with extra dependencies beyond the > standard Java class libraries and the JCR API. > Currently jackrabbit-jcr-commons depends on both commons-collections and > slf4j-api, but both dependencies are relatively isolated and could be dropped > with relatively little effort. Both dependency changes may be backwards > incompatible with existing clients, but since the impact is reasonably small > and easy to resolve I'd be OK doing this in 1.5. > [1] http://markmail.org/message/724ruk4l7b5rjtan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1617) Remove commons-collections and slf4j-api dependencies from jcr-commons
[ https://issues.apache.org/jira/browse/JCR-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-1617. Resolution: Fixed Resolved in revision 658630. > Remove commons-collections and slf4j-api dependencies from jcr-commons > -- > > Key: JCR-1617 > URL: https://issues.apache.org/jira/browse/JCR-1617 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-jcr-commons >Reporter: Jukka Zitting >Assignee: Jukka Zitting > Fix For: 1.5 > > Attachments: JCR-1617.patch > > > As noted in JCR-1615 and discussed on the mailing list [1] it would be good > if jackrabbit-jcr-commons didn't come with extra dependencies beyond the > standard Java class libraries and the JCR API. > Currently jackrabbit-jcr-commons depends on both commons-collections and > slf4j-api, but both dependencies are relatively isolated and could be dropped > with relatively little effort. Both dependency changes may be backwards > incompatible with existing clients, but since the impact is reasonably small > and easy to resolve I'd be OK doing this in 1.5. > [1] http://markmail.org/message/724ruk4l7b5rjtan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1602) DbDatastore: Problems indexing pdf file
[ https://issues.apache.org/jira/browse/JCR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1602: --- Fix Version/s: (was: 1.4) core 1.4.5 > DbDatastore: Problems indexing pdf file > --- > > Key: JCR-1602 > URL: https://issues.apache.org/jira/browse/JCR-1602 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: 1.4 >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: core 1.4.5 > > > As reported by Claus Köll: > When importing a pdf file into a repository configured with a DbDataStore the > following exception occurs. This happens only when using the DbDataStore with > copyWhenReading=true > java.io.IOException: Stream closed >at > java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:156) >at java.io.BufferedInputStream.read(BufferedInputStream.java:315) >at > org.apache.jackrabbit.core.data.db.TempFileInputStream.read(TempFileInputStream.java:107) >at java.io.BufferedInputStream.read1(BufferedInputStream.java:265) >at java.io.BufferedInputStream.read(BufferedInputStream.java:324) >at java.io.BufferedInputStream.fill(BufferedInputStream.java:229) >at java.io.BufferedInputStream.read(BufferedInputStream.java:246) >at java.io.FilterInputStream.read(FilterInputStream.java:89) >at java.io.PushbackInputStream.read(PushbackInputStream.java:141) >at org.pdfbox.io.PushBackInputStream.peek(PushBackInputStream.java:71) >at org.pdfbox.io.PushBackInputStream.isEOF(PushBackInputStream.java:88) >at org.pdfbox.pdfparser.PDFParser.parseObject(PDFParser.java:370) >at org.pdfbox.pdfparser.PDFParser.parse(PDFParser.java:176) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
jackrabbit-core 1.4.5 release plan
Hi, There's some push for more jackrabbit-core fixes to be going out in the 1.4 branch, so I've created a "core 1.4.5" version in Jira to track those. Currently I'm thinking more about Jackrabbit 1.5, but feel free to use the "core 1.4.5" version as a target for any bug fixes that should also be released from the 1.4 branch. I'll move forward once we have enough demand or pending fixes to justify cutting the release. BR, Jukka Zitting
[jira] Updated: (JCR-1310) Webdav: Drop xerces dependency
[ https://issues.apache.org/jira/browse/JCR-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1310: --- Attachment: JCR-1310-jukka.patch How about using the SerializingContentHandler class from JCR-1350? I attached (JCR-1310-jukka.patch) a modified version of your patch that uses SerializingContentHandler instead of the new o.a.j.util.xml classes. I don't have the litmus suite or a spi2dav setup readily at hand, so I only tested this with normal "mvn clean install". Perhaps we could automate those tests somehow? Apart from the different serialization class there are slight changes between your and my patches: * I used the ByteArrayOutputStream directly instead of a StringRequestEntity to implement the methods in XmlRequestEntity * I don't set the character encoding in the content type header, as currently SerializingContentHandler let's the JAXP implementation selects the default encoding * I don't close() the ByteArrayOutputStreams Also, should we use "application/xml" instead of "text/xml" as the XML content type? > Webdav: Drop xerces dependency > -- > > Key: JCR-1310 > URL: https://issues.apache.org/jira/browse/JCR-1310 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-webdav >Reporter: angela >Assignee: angela >Priority: Minor > Attachments: JCR-1261.drop-xerces.patch, JCR-1310-jukka.patch, > JCR-1310.diff > > -- 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-1310) Webdav: Drop xerces dependency
[ https://issues.apache.org/jira/browse/JCR-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598639#action_12598639 ] jukkaz edited comment on JCR-1310 at 5/21/08 6:22 AM: - How about using the SerializingContentHandler class from JCR-1350? I attached (JCR-1310-jukka.patch) a modified version of your patch that uses SerializingContentHandler instead of the new o.a.j.util.xml classes. I don't have the litmus suite or a spi2dav setup readily at hand, so I only tested this with normal "mvn clean install". Perhaps we could automate those tests somehow? Apart from the different serialization class there are slight changes between your and my patches: * I used the ByteArrayOutputStream directly instead of a StringRequestEntity to implement the methods in XmlRequestEntity * I don't set the character encoding in the content type header, as currently SerializingContentHandler lets the JAXP implementation select the default encoding * I don't close() the ByteArrayOutputStreams Also, should we use "application/xml" instead of "text/xml" as the XML content type? was (Author: jukkaz): How about using the SerializingContentHandler class from JCR-1350? I attached (JCR-1310-jukka.patch) a modified version of your patch that uses SerializingContentHandler instead of the new o.a.j.util.xml classes. I don't have the litmus suite or a spi2dav setup readily at hand, so I only tested this with normal "mvn clean install". Perhaps we could automate those tests somehow? Apart from the different serialization class there are slight changes between your and my patches: * I used the ByteArrayOutputStream directly instead of a StringRequestEntity to implement the methods in XmlRequestEntity * I don't set the character encoding in the content type header, as currently SerializingContentHandler let's the JAXP implementation selects the default encoding * I don't close() the ByteArrayOutputStreams Also, should we use "application/xml" instead of "text/xml" as the XML content type? > Webdav: Drop xerces dependency > -- > > Key: JCR-1310 > URL: https://issues.apache.org/jira/browse/JCR-1310 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-webdav >Reporter: angela >Assignee: angela >Priority: Minor > Attachments: JCR-1261.drop-xerces.patch, JCR-1310-jukka.patch, > JCR-1310.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1310) Webdav: Drop xerces dependency
[ https://issues.apache.org/jira/browse/JCR-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598648#action_12598648 ] angela commented on JCR-1310: - > I don't have the litmus suite or a spi2dav setup readily at hand, so I only > tested this with > normal "mvn clean install". hm... that doesn't help in this case. the namespace problems are only detected upon those tests. could you test it? it takes forever to have everything installed and carefully looked at. and basically i don't have time for it. litmus can be found here: http://www.webdav.org/neon/litmus/ spi2dav: - tests including impersonation, clone and across-workspace-copy are not implemented. - some tests fail for imcompatibility between 170 and 283 functionaly already built into jackrabbit-core. - running the tests a change to the default web.xml (missing-auth-param) - running the tests requires the webapp to contain the tck test content. > Perhaps we could automate those tests somehow? i don't know how. if you find a way to do so, that would be great. > Apart from the different serialization class there are slight changes between > your and > my patches: fine with me, as long as everything works as expected. > Also, should we use "application/xml" instead of "text/xml" as the XML > content type? no preference. i used text/xml since this is the mimetype mapping defined in the mimetypes.properties (jcr-server)... chances are, that the text/xml is wide-spread. so you would have to replace the other locations as well for consistency reasons... if you have time to so... otherwise i would leave it and have an extra enhancement issue for that. > Webdav: Drop xerces dependency > -- > > Key: JCR-1310 > URL: https://issues.apache.org/jira/browse/JCR-1310 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-webdav >Reporter: angela >Assignee: angela >Priority: Minor > Attachments: JCR-1261.drop-xerces.patch, JCR-1310-jukka.patch, > JCR-1310.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1621) Use application/xml as the XML media type
Use application/xml as the XML media type - Key: JCR-1621 URL: https://issues.apache.org/jira/browse/JCR-1621 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Jukka Zitting Priority: Minor As noted in JCR-1310, at least in jackrabbit-webapp but possibly also elsewhere we should be using application/xml instead of text/xml as the content type when serving XML over HTTP. The text/xml type has been widely criticized because of character encoding issues (see for example http://www.xml.com/pub/a/2004/07/21/dive.html), and there has even been an attempt to officially deprecate text/xml because of this. The application/xml type doesn't suffer from these issues, and is thus a better choice when serving XML. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1310) Webdav: Drop xerces dependency
[ https://issues.apache.org/jira/browse/JCR-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598689#action_12598689 ] Jukka Zitting commented on JCR-1310: OK, I'll take a look at the tests (and possibly automating them) later today. Re: application/xml; I filed a new issue for that, see JCR-1621. > Webdav: Drop xerces dependency > -- > > Key: JCR-1310 > URL: https://issues.apache.org/jira/browse/JCR-1310 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-webdav >Reporter: angela >Assignee: angela >Priority: Minor > Attachments: JCR-1261.drop-xerces.patch, JCR-1310-jukka.patch, > JCR-1310.diff > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1621) Use application/xml as the XML media type
[ https://issues.apache.org/jira/browse/JCR-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598695#action_12598695 ] Julian Reschke commented on JCR-1621: - Hm. If it ain't broke, don't fix it. As long as the server actually properly declares the character set in the Content-Type, this is a non-issue. On the other hand, switching to application/xml theoretically could break ancient clients. So be careful :-). > Use application/xml as the XML media type > - > > Key: JCR-1621 > URL: https://issues.apache.org/jira/browse/JCR-1621 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-webdav >Reporter: Jukka Zitting >Priority: Minor > > As noted in JCR-1310, at least in jackrabbit-webapp but possibly also > elsewhere we should be using application/xml instead of text/xml as the > content type when serving XML over HTTP. > The text/xml type has been widely criticized because of character encoding > issues (see for example http://www.xml.com/pub/a/2004/07/21/dive.html), and > there has even been an attempt to officially deprecate text/xml because of > this. The application/xml type doesn't suffer from these issues, and is thus > a better choice when serving XML. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1621) Use application/xml as the XML media type
[ https://issues.apache.org/jira/browse/JCR-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598697#action_12598697 ] angela commented on JCR-1621: - quickly searched for text/xml throughout the jackrabbit project: jackrabbit-api - JackrabbitNodeTypeManager (1 usage) jackrabbit-jcr-server: - XmlHandler.java (2 usages) - mimetypes.properties (1 usage) - DefaultItemCollection (1 usage) - DefaultItemResource (1 usage) jackrabbit-text-extractor : - README (1 usage) - CompositeTextExtractorTest.java (1 usage) - XMLTextExtractor.java (1 usage) jackrabbit-webdav : - WebdavResponseImpl (1 usage) - XMLRequestEntity (1 usage) sandbox/spi2dav: - RepositoryServiceImpl (1 usage) - XMLTextExtractorTest.java (7 usages) > Use application/xml as the XML media type > - > > Key: JCR-1621 > URL: https://issues.apache.org/jira/browse/JCR-1621 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-webdav >Reporter: Jukka Zitting >Priority: Minor > > As noted in JCR-1310, at least in jackrabbit-webapp but possibly also > elsewhere we should be using application/xml instead of text/xml as the > content type when serving XML over HTTP. > The text/xml type has been widely criticized because of character encoding > issues (see for example http://www.xml.com/pub/a/2004/07/21/dive.html), and > there has even been an attempt to officially deprecate text/xml because of > this. The application/xml type doesn't suffer from these issues, and is thus > a better choice when serving XML. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Simple CI documentation
Hi, For those who are interested, I quickly summarized our current Hudson CI setup at http://jackrabbit.apache.org/continuous-integration.html. PS. Does anyone foresee any need for the Jackrabbit zone we used to run Continuum previously? If not, I'll inform infrastructure@ that we don't need the zone anymore. BR, Jukka Zitting
[jira] Assigned: (JCR-1286) FilterImpl.getStringValue() does not use custom converter class specified in @Field annotation
[ https://issues.apache.org/jira/browse/JCR-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1286: --- Assignee: Christophe Lombart > FilterImpl.getStringValue() does not use custom converter class specified in > @Field annotation > -- > > Key: JCR-1286 > URL: https://issues.apache.org/jira/browse/JCR-1286 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-ocm >Affects Versions: 1.4 > Environment: jackrabbit-ocm-1.4-20071210.145858-1 > java version "1.5.0_13" >Reporter: Paul Mietz Egli >Assignee: Christophe Lombart > > I have a POJO with the following field: > @Field(converter = LocaleConverter.class) > private Localelocale; > When I attempt to query for objects based on this field, I get a > NullPointerException: > java.lang.NullPointerException > at > org.apache.jackrabbit.ocm.query.impl.FilterImpl.getStringValue(FilterImpl.java:281) > at > org.apache.jackrabbit.ocm.query.impl.FilterImpl.addEqualTo(FilterImpl.java:129) > FilterImpl should preferentially use the atomic type converter defined in the > @Field annotation to convert the value, then fallback to the global > converters. Converting the Locale to a string for use in the query is a > workaround, but the logic for string conversion should only reside in my > LocaleConverter class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1286) FilterImpl.getStringValue() does not use custom converter class specified in @Field annotation
[ https://issues.apache.org/jira/browse/JCR-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1286. - Resolution: Fixed Fix Version/s: 1.5 >From now, the Filter is using the converter if it is specified in the mapping >definition. Let me know if something is wrong Thanks > FilterImpl.getStringValue() does not use custom converter class specified in > @Field annotation > -- > > Key: JCR-1286 > URL: https://issues.apache.org/jira/browse/JCR-1286 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-ocm >Affects Versions: 1.4 > Environment: jackrabbit-ocm-1.4-20071210.145858-1 > java version "1.5.0_13" >Reporter: Paul Mietz Egli >Assignee: Christophe Lombart > Fix For: 1.5 > > > I have a POJO with the following field: > @Field(converter = LocaleConverter.class) > private Localelocale; > When I attempt to query for objects based on this field, I get a > NullPointerException: > java.lang.NullPointerException > at > org.apache.jackrabbit.ocm.query.impl.FilterImpl.getStringValue(FilterImpl.java:281) > at > org.apache.jackrabbit.ocm.query.impl.FilterImpl.addEqualTo(FilterImpl.java:129) > FilterImpl should preferentially use the atomic type converter defined in the > @Field annotation to convert the value, then fallback to the global > converters. Converting the Locale to a string for use in the query is a > workaround, but the logic for string conversion should only reside in my > LocaleConverter class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1537) ClassDescriptor.hasIdField() fails if id is declared in upper class
[
https://issues.apache.org/jira/browse/JCR-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart reassigned JCR-1537:
---
Assignee: Christophe Lombart
> ClassDescriptor.hasIdField() fails if id is declared in upper class
> ---
>
> Key: JCR-1537
> URL: https://issues.apache.org/jira/browse/JCR-1537
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-ocm
>Affects Versions: 1.5
> Environment: Mac OS X, JVM 1.5
>Reporter: Stephane Landelle
>Assignee: Christophe Lombart
> Attachments: jackrabbit-ocm.patch
>
> Original Estimate: 0.02h
> Remaining Estimate: 0.02h
>
> org.apache.jackrabbit.ocm.mapper.model.ClassDescriptor.hasIdField() looks up
> only current class and not the whole hierarchy, so it fails when the id field
> is declared in a upper class.
> hasIdField should use getIdFieldDescriptor and not access idFieldDescriptor
> field directly, as follows :
> public boolean hasIdField() {
> return (this.getIdFieldDescriptor() != null && this
> .getIdFieldDescriptor().isId());
> }
> Please find patch enclosed.
> Sincerely yours,
> Stéphane Landelle
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1537) ClassDescriptor.hasIdField() fails if id is declared in upper class
[
https://issues.apache.org/jira/browse/JCR-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christophe Lombart resolved JCR-1537.
-
Resolution: Fixed
Fix Version/s: 1.5
Patch applied - Thanks
Let me know if something is wrong
> ClassDescriptor.hasIdField() fails if id is declared in upper class
> ---
>
> Key: JCR-1537
> URL: https://issues.apache.org/jira/browse/JCR-1537
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-ocm
>Affects Versions: 1.5
> Environment: Mac OS X, JVM 1.5
>Reporter: Stephane Landelle
>Assignee: Christophe Lombart
> Fix For: 1.5
>
> Attachments: jackrabbit-ocm.patch
>
> Original Estimate: 0.02h
> Remaining Estimate: 0.02h
>
> org.apache.jackrabbit.ocm.mapper.model.ClassDescriptor.hasIdField() looks up
> only current class and not the whole hierarchy, so it fails when the id field
> is declared in a upper class.
> hasIdField should use getIdFieldDescriptor and not access idFieldDescriptor
> field directly, as follows :
> public boolean hasIdField() {
> return (this.getIdFieldDescriptor() != null && this
> .getIdFieldDescriptor().isId());
> }
> Please find patch enclosed.
> Sincerely yours,
> Stéphane Landelle
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: ClusterNode and snapshot question.
Hi Ian, To bring up a new node into a cluster, I'd do the following: (1) Stop an already existing node (2) Make a deep copy of the existing node, starting from the repository home (3) Assign a unique cluster node id to this new node (4) Startup both nodes again Stopping the source node before copying ensures that indices are consistent. In (2) the revision.log will get copied as well, so the new cluster node will start from the same revision as the source node. Kind regards Dominique On 5/21/08, Ian Boston <[EMAIL PROTECTED]> wrote: > I have a question about ClusterNode and the Journal. > > If I bring a new app server node into a Jackrabbit cluster, the journal > gets replayed from scratch, this can take some time if the cluster has been > running for some time. I would like to avoid this if possible. > > It would be nice to be able to snapshot the local state of an app server, > and use that to a) seed new app servers as they joined the cluster b) > truncate the redo log to prevent eternal growth. > > Is this the right way to achieve a fast start of a new app server in the > cluster ? > Is it necessary to run the journal from scratch (I assume it is due to the > indexing operations)? > Has anyone already looked at this ? > > I searched the lists but I couldn't find anything. > > Thanks > Ian > > > >
[jira] Created: (JCR-1622) Session.getUserID returns first principal in the set obtained from Subject.getPrincipals()
Session.getUserID returns first principal in the set obtained from Subject.getPrincipals() -- Key: JCR-1622 URL: https://issues.apache.org/jira/browse/JCR-1622 Project: Jackrabbit Issue Type: Bug Components: security Reporter: angela Assignee: angela Priority: Minor Fix For: 1.5 this may lead to a wrong value for the UserID (e.g. the name of a Group principal). jsr 170 defines the getUserID() to return " the user ID associated with this Session." and implies (javadoc) that the method has a relation to the login. This issues has already been partially addressed while working on jsr 283 access control (trunk). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
