You are right, lastAccessTime() isn't included until Java 7 :(
http://openjdk.java.net/projects/nio/javadoc/java/nio/file/attribute/BasicFileAttributes.html#lastAccessTime%28%29
On Thu, Oct 13, 2011 at 8:22 AM, Thomas Mueller wrote:
> Hi,
>
> > Why don't check the "access time", instead of usin
Hi,
> Why don't check the "access time", instead of using the "modification time"
> for this? At least in UNIX / Linux you can check when a file was accesed last
> time.
First of all, in Java you can't. Second, many file systems don't update that
value.
Regards,
Thomas
Why don't check the "access time", instead of using the "modification time"
for this? At least in UNIX / Linux you can check when a file was accesed
last time.
On Wed, Oct 12, 2011 at 1:42 PM, Thomas Mueller wrote:
> Hi,
>
> > I think we should drop support for multiple distinct repositories
>
>
[
https://issues.apache.org/jira/browse/JCR-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Köll updated JCR-2892:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Large fetch sizes have potentially d
[
https://issues.apache.org/jira/browse/JCR-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13126362#comment-13126362
]
Claus Köll commented on JCR-2892:
-
Modified (fetch Size 0 per default) patch applied in rev
[
https://issues.apache.org/jira/browse/JCR-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Köll updated JCR-2892:
Fix Version/s: 2.3.2
> Large fetch sizes have potentially deleterious effects on VM memory
> requirement
[
https://issues.apache.org/jira/browse/JCR-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13126059#comment-13126059
]
Michael Dürig commented on JCR-3110:
I think the else branch should be
defs.add(new
The else branch should probably be
defs.add(new QPropertyDefinitionImpl(pd));
I created JCR-3110 [1] for this.
Michael
[1] https://issues.apache.org/jira/browse/JCR-3110
On 12.10.11 6:34, Dave Brosius wrote:
The following method in class /
/
/org.apache.jackrabbit.spi.commons.QNodeTyp
QNodeTypeDefinitionImpl.getSerializablePropertyDefs() might return non
serializable property definitions
-
Key: JCR-3110
URL: https://issues.apache.org/jira/b
[
https://issues.apache.org/jira/browse/JCR-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-3093:
Resolution: Fixed
Fix Version/s: 2.3.2
Status: Resolved (was: Patch Available)
> Inconsistency
[
https://issues.apache.org/jira/browse/JCR-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125921#comment-13125921
]
angela commented on JCR-3093:
-
played around with the possibilities listed above. retrieving the
[
https://issues.apache.org/jira/browse/JCR-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCR-2073:
Summary: Redundant calls to RepositoryService.getPropertyInfo() for
jcr:uuid and jcr:mixinTypes (was: Redundant call
[
https://issues.apache.org/jira/browse/JCR-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125902#comment-13125902
]
Julian Reschke commented on JCR-3069:
-
Another issue: the test suite alternates through
[
https://issues.apache.org/jira/browse/JCR-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu resolved JCR-3109.
--
Resolution: Fixed
Fix Version/s: 2.3.2
Fixed in rev 1182384.
> Move Persi
[
https://issues.apache.org/jira/browse/JCR-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated JCR-3109:
-
Description: The subject pretty much sums it up. The PMTest should be
placed together with the othe
[
https://issues.apache.org/jira/browse/JCR-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated JCR-3109:
-
Description: ;The subject pretty much sums it up. The PMTest should be
placed together with the oth
Move PersistenceManagerTest from o.a.j.core to o.a.j.core.persistence
-
Key: JCR-3109
URL: https://issues.apache.org/jira/browse/JCR-3109
Project: Jackrabbit Content Repository
[
https://issues.apache.org/jira/browse/JCR-2989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu resolved JCR-2989.
--
Resolution: Fixed
Fix Version/s: 2.3.2
Fixed in revision 1182367 and 1182368.
[
https://issues.apache.org/jira/browse/JCR-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated JCR-3108:
-
Fix Version/s: (was: 2.4)
2.3.2
> SQL2 ISDESCENDANTNODE can throw Boolea
+1 checked ok
On Wed, Oct 12, 2011 at 12:25 PM, Jukka Zitting wrote:
> Hi,
>
> A candidate for the Jackrabbit 2.3.1 release is available at:
>
>http://people.apache.org/~jukka/jackrabbit/2.3.1/
>
> The release candidate is a zip archive of the sources in:
>
>http://svn.apache.org/repos/as
Hi,
> I think we should drop support for multiple distinct repositories
Removing features from existing classes is problematic... What about a
config option or a new class where this isn't supported.
>The upside would be that with
>something like that we'd be able to avoid the troublesome need
Hi,
A candidate for the Jackrabbit 2.3.1 release is available at:
http://people.apache.org/~jukka/jackrabbit/2.3.1/
The release candidate is a zip archive of the sources in:
http://svn.apache.org/repos/asf/jackrabbit/tags/2.3.1/
The SHA1 checksum of the archive is 55ea46caa9c4232d60c5a
Hi,
On Wed, Oct 12, 2011 at 11:34 AM, Thomas Mueller wrote:
> Please note the data store can be shared by multiple *processes* (multiple
> distinct repositories and multiple cluster nodes).
I think we should drop support for multiple distinct repositories
using the same data store. For multiple
[
https://issues.apache.org/jira/browse/JCR-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated JCR-3108:
-
Fix Version/s: (was: 2.3.2)
2.4
> SQL2 ISDESCENDANTNODE can throw Boolea
Hi,
Please note the data store can be shared by multiple *processes* (multiple
distinct repositories and multiple cluster nodes).
Keeping a separate log is problematic, as accessing the separate log would
need to be synchronized somehow. Keeping the list in memory is even more
problematic (not to
Hi,
After the 2.3.0 release I let the trunk version be 2.3.1-SNAPSHOT and
now after cutting the 2.3.1 release the version became 2.3.2-SNAPSHOT.
While this is conceptually correct and gives correct default values
for the Maven release plugin, it does make it a bit cumbersome for
dowstream projects
[
https://issues.apache.org/jira/browse/JCR-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu resolved JCR-3108.
--
Resolution: Fixed
Fix Version/s: 2.3.2
Fixed in revision #1182281.
> SQL2
[
https://issues.apache.org/jira/browse/JCR-3108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu reassigned JCR-3108:
Assignee: Alex Parvulescu
> SQL2 ISDESCENDANTNODE can throw BooleanQuery#TooManyClauses i
SQL2 ISDESCENDANTNODE can throw BooleanQuery#TooManyClauses if there are too
many matching child nodes
--
Key: JCR-3108
URL: https://issues.apache.org/jira/browse/
Hi,
On Wed, Oct 12, 2011 at 10:22 AM, Thomas Mueller wrote:
> However I'm afraid I don't know a better way to solve the problem (mark the
> file as still being used). Suggestions are always welcome of course.
We could keep a separate log of the last access times of records.
Or better yet, since
On Wed, Oct 12, 2011 at 10:22 AM, Thomas Mueller wrote:
> Hi,
>
> > This means that every time a file is accessed is like has been modified
> and this is not true.
>
> When garbage collection is running, yes.
>
I don't understand why the file mod-time need to be updated when
DataStoreGarbageColl
[
https://issues.apache.org/jira/browse/JCR-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-3102:
---
Issue Type: Improvement (was: Task)
> InternalVersion.getFrozenNode confused about root version?
>
[
https://issues.apache.org/jira/browse/JCR-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-2892:
---
Fix Version/s: (was: 2.3.1)
> Large fetch sizes have potentially deleterious effects on VM memo
[
https://issues.apache.org/jira/browse/JCR-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-3098:
---
Fix Version/s: (was: 2.3.1)
> Add hit miss statistics and logging to caches
> -
[
https://issues.apache.org/jira/browse/JCR-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125668#comment-13125668
]
Bart van der Schans commented on JCR-2968:
--
Hi Jukka, Christian,
I agree about the
[
https://issues.apache.org/jira/browse/JCR-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg updated JCR-3107:
---
Component/s: query
> Speed up hierarchy cache initialization
>
Hi,
> This means that every time a file is accessed is like has been modified and
> this is not true.
When garbage collection is running, yes.
> incremental backups does not make sense
If incremental backup only checks the last modified time, then it's a problem,
I agree. However I'm afraid I
On 2011-10-12 07:34, Dave Brosius wrote:
The following method in class /
/
/org.apache.jackrabbit.spi.commons.QNodeTypeDefinitionImpl /
would appear to return a set of serializable property definitions.
However, it would appear that it just returns a set-version of the
passed in parameter,
Hi there.
I'm curious about the behabior of the
FileDataStore.getRecordIfStored(DataIdentifier identifier) method: when
access a DataRecord, it update the modification time of the file. This means
that every time a file is accessed is like has been modified and this is not
true.
The main reason o
39 matches
Mail list logo
