Return-Path: 
 <dev-return-32617-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org>
X-Original-To: apmail-jackrabbit-dev-archive@www.apache.org
Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id C77F09F17
	for <apmail-jackrabbit-dev-archive@www.apache.org>;
 Fri,  7 Oct 2011 14:05:51 +0000 (UTC)
Received: (qmail 84026 invoked by uid 500); 7 Oct 2011 14:05:51 -0000
Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org
Received: (qmail 83982 invoked by uid 500); 7 Oct 2011 14:05:51 -0000
Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@jackrabbit.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@jackrabbit.apache.org>
List-Post: <mailto:dev@jackrabbit.apache.org>
List-Id: <dev.jackrabbit.apache.org>
Reply-To: dev@jackrabbit.apache.org
Delivered-To: mailing list dev@jackrabbit.apache.org
Received: (qmail 83971 invoked by uid 99); 7 Oct 2011 14:05:51 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Oct 2011 14:05:51 +0000
X-ASF-Spam-Status: No, hits=-2000.5 required=5.0
	tests=ALL_TRUSTED,RP_MATCHES_RCVD
X-Spam-Check-By: apache.org
Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Oct 2011 14:05:50 +0000
Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116])
	by hel.zones.apache.org (Postfix) with ESMTP id B7C302AE17B
	for <dev@jackrabbit.apache.org>; Fri,  7 Oct 2011 14:05:29 +0000 (UTC)
Date: Fri, 7 Oct 2011 14:05:29 +0000 (UTC)
From: "Jukka Zitting (Commented) (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: 
 <493296237.7998.1317996329754.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <833071143.7928.1317995009676.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (JCR-3102) InternalVersion.getFrozenNode
 confused about root version?
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/JCR-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122812#comment-13122812 ] 

Jukka Zitting commented on JCR-3102:
------------------------------------

It looks like the null reference in javadoc was added in revision 122838 based on code from revision 53784 [2]. So this dates back to time before JCR 1.0. I guess the javadoc is simply outdated and refers back to the initial idea of the root version not having any frozen state. AFAICT the idea of including basic details of the node in the root version came a bit later.

[1] http://svn.apache.org/viewvc?view=revision&revision=122838
[2] http://svn.apache.org/viewvc?view=revision&revision=53784
                
> InternalVersion.getFrozenNode confused about root version?
> ----------------------------------------------------------
>
>                 Key: JCR-3102
>                 URL: https://issues.apache.org/jira/browse/JCR-3102
>             Project: Jackrabbit Content Repository
>          Issue Type: Task
>          Components: jackrabbit-core
>            Reporter: Julian Reschke
>            Priority: Minor
>
> It seems the javadoc for InternalVersion.getFrozenNode  is confused:
>      * Returns the frozen node of this version or <code>null</code> if this is
>      * the root version.
> AFAIU, the frozen node of the root version is always present to capture the node type of the versionable node.
> Does anybody recall how this got here? (SVN says it has been there forever)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira