Derby
  1. Derby
  2. DERBY-1934

Reference Manual updates - J2EE Compliance: Java Transaction API and javax.sql Extensions

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.2.1.6
    • Fix Version/s: 10.3.1.4
    • Component/s: Documentation
    • Labels:
      None

      Description

      J2EE Compliance: Java Transaction API and javax.sql Extensions:

      Section = javax.sql:JDBC Extensions
      File = http://db.apache.org/derby/docs/dev/ref/rrefjta18596.html
      Update =
      This URL no longer exists: (For more details about these extensions, see http://java.sun.com/products/jdbc/jdbc20.stdext.javadoc/javax/sql/package-summary.html). The page that has this information, although you have to browse to the section called JDBC 2.0 Optional Package API is http://java.sun.com/products/jdbc/download.html

      1. derby1934_1.diff
        5 kB
        Laura Stewart
      2. rrefjta18596.html
        7 kB
        Laura Stewart
      3. derby1934_2.diff
        15 kB
        Laura Stewart
      4. derby1934_html2.zip
        14 kB
        Laura Stewart
      5. derby1934_3.diff
        16 kB
        Laura Stewart
      6. derby1934_html3.zip
        14 kB
        Laura Stewart
      7. derby1934_4.diff
        16 kB
        Laura Stewart
      8. derby1934_5.diff
        15 kB
        Laura Stewart

        Activity

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open In Progress In Progress
        172d 22h 43m 1 Laura Stewart 27/Mar/07 19:39
        In Progress In Progress Resolved Resolved
        31d 1h 46m 1 Laura Stewart 27/Apr/07 21:26
        Resolved Resolved Closed Closed
        52d 19h 43m 1 Laura Stewart 19/Jun/07 17:10
        Gavin made changes -
        Workflow jira [ 12386312 ] Default workflow, editable Closed status [ 12798368 ]
        Laura Stewart made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Laura Stewart made changes -
        Derby Info [Patch Available]
        Status In Progress [ 3 ] Resolved [ 5 ]
        Fix Version/s 10.3.0.0 [ 12310800 ]
        Resolution Fixed [ 1 ]
        Hide
        Laura Stewart added a comment -

        Committed revision 533210.

        Show
        Laura Stewart added a comment - Committed revision 533210.
        Laura Stewart made changes -
        Attachment derby1934_5.diff [ 12356434 ]
        Hide
        Laura Stewart added a comment -

        Minor update because out of sync with source code.
        New patch derby-1934_5.diff

        Show
        Laura Stewart added a comment - Minor update because out of sync with source code. New patch derby-1934_5.diff
        Hide
        Kim Haase added a comment -

        Yes, indeed. Now I hope someone will give the patch a technical okay!

        Show
        Kim Haase added a comment - Yes, indeed. Now I hope someone will give the patch a technical okay!
        Laura Stewart made changes -
        Attachment derby1934_4.diff [ 12356425 ]
        Hide
        Laura Stewart added a comment -

        This patch updated the minor subject/verb issue that Kim noticed.

        Show
        Laura Stewart added a comment - This patch updated the minor subject/verb issue that Kim noticed.
        Hide
        Kim Haase added a comment -

        I'll leave that to a technical reviewer ... but I just noticed a problem with agreement of subject and verb in rrefjta16677.html (I think it's been there for a while):

        "Implementation of two of the JDBC interfaces, javax.sql.ConnectionPoolDataSource and javax.sql.PooledConnection, provide this support."

        The subject is "implementation", so the verb should be "provides". Since you've fixed part of this sentence, it might be worth while to make that last fix.

        Show
        Kim Haase added a comment - I'll leave that to a technical reviewer ... but I just noticed a problem with agreement of subject and verb in rrefjta16677.html (I think it's been there for a while): "Implementation of two of the JDBC interfaces, javax.sql.ConnectionPoolDataSource and javax.sql.PooledConnection, provide this support." The subject is "implementation", so the verb should be "provides". Since you've fixed part of this sentence, it might be worth while to make that last fix.
        Laura Stewart made changes -
        Attachment derby1934_3.diff [ 12355359 ]
        Attachment derby1934_html3.zip [ 12355360 ]
        Hide
        Laura Stewart added a comment -

        Updated the description of DataSource. Please review to ensure that it is accurate now.

        Show
        Laura Stewart added a comment - Updated the description of DataSource. Please review to ensure that it is accurate now.
        Hide
        Kim Haase added a comment -

        You're right, there aren't any trademark symbols in the Ref Guide. I think we may as well keep the Ref Guide consistent with itself, so please ignore that comment.

        The Admin Guide has both IBM and Sun trademarks in a number of files; for example, look in the file

        adminguide/cadminapps810777.dita

        There is one trademark symbol in the Dev Guide (devguide/cdevdvlp14839.dita). I think all the other books are free of them.

        These are neither Sun nor IBM docs, so I'm not sure what we need to do in terms of observing these companies' trademarks; we may well be covered by that trademark file at the end. We might be able to consider removing them from the Admin and Dev Guides. Perhaps we should each do a little research on this and see what we find.

        Show
        Kim Haase added a comment - You're right, there aren't any trademark symbols in the Ref Guide. I think we may as well keep the Ref Guide consistent with itself, so please ignore that comment. The Admin Guide has both IBM and Sun trademarks in a number of files; for example, look in the file adminguide/cadminapps810777.dita There is one trademark symbol in the Dev Guide (devguide/cdevdvlp14839.dita). I think all the other books are free of them. These are neither Sun nor IBM docs, so I'm not sure what we need to do in terms of observing these companies' trademarks; we may well be covered by that trademark file at the end. We might be able to consider removing them from the Admin and Dev Guides. Perhaps we should each do a little research on this and see what we find.
        Hide
        Laura Stewart added a comment -

        Hi Kim -

        In your comment on 3/30 you mentioned:
        "There's a trademark tag in DITA that you might want to use for the first occurrence of "Java" in the file. There are other occurrences in the books. "

        I searched and I could not find another instance of "Java" trademarked in the Ref Guide. In fact there are many occurances of "Java" without the trademark. Also I think that the file rreftrademarks.dita covers all the issues with trademarks. My impression is that since that file exists in the book that we don't have to mark each individual occurance of a trademark.

        If you really think that it is necessary to mark this occurance, plesae point me to another dita file that has the tagging so that I can see it. Thanks!

        Show
        Laura Stewart added a comment - Hi Kim - In your comment on 3/30 you mentioned: "There's a trademark tag in DITA that you might want to use for the first occurrence of "Java" in the file. There are other occurrences in the books. " I searched and I could not find another instance of "Java" trademarked in the Ref Guide. In fact there are many occurances of "Java" without the trademark. Also I think that the file rreftrademarks.dita covers all the issues with trademarks. My impression is that since that file exists in the book that we don't have to mark each individual occurance of a trademark. If you really think that it is necessary to mark this occurance, plesae point me to another dita file that has the tagging so that I can see it. Thanks!
        Hide
        Kim Haase added a comment -

        I guess I was being a little cavalier about that – sorry.

        Unless I'm mistaken, there's nothing unusual about Derby's implementation of DataSource – is there? So all you really need to say is what a DataSource is and what it's used for.

        Show
        Kim Haase added a comment - I guess I was being a little cavalier about that – sorry. Unless I'm mistaken, there's nothing unusual about Derby's implementation of DataSource – is there? So all you really need to say is what a DataSource is and what it's used for.
        Hide
        Laura Stewart added a comment -

        I have to agree with Dan... I dont' think that we should ever "verbatim" resuse text from a source that is not another open source. It just invites questions of legality. Better to paraphrase or simply point to the other source. In this case, I think that we can summarize what Derby implements of the DataSource interface. I'll look more closely at the links Lance and you provided for the description and will come up with some other wording that you can review.

        Show
        Laura Stewart added a comment - I have to agree with Dan... I dont' think that we should ever "verbatim" resuse text from a source that is not another open source. It just invites questions of legality. Better to paraphrase or simply point to the other source. In this case, I think that we can summarize what Derby implements of the DataSource interface. I'll look more closely at the links Lance and you provided for the description and will come up with some other wording that you can review.
        Hide
        Kim Haase added a comment -

        Oh, and in response to some of your earlier questions, Laura – sorry I missed them –

        "Factory" is a pretty common Java term; lots of packages have interfaces that have the name Factory in them. So I think the term will be understood by Java users.

        And yes, we won't need to worry about changing the WWD example after all. DriverManager is just fine. Our examples are outside a Java EE environment, so we aren't using JNDI, and in that case DriverManager is the right thing to use.

        There's a trademark tag in DITA that you might want to use for the first occurrence of "Java" in the file. There are other occurrences in the books.

        Show
        Kim Haase added a comment - Oh, and in response to some of your earlier questions, Laura – sorry I missed them – "Factory" is a pretty common Java term; lots of packages have interfaces that have the name Factory in them. So I think the term will be understood by Java users. And yes, we won't need to worry about changing the WWD example after all. DriverManager is just fine. Our examples are outside a Java EE environment, so we aren't using JNDI, and in that case DriverManager is the right thing to use. There's a trademark tag in DITA that you might want to use for the first occurrence of "Java" in the file. There are other occurrences in the books.
        Hide
        Kim Haase added a comment -

        To Dan: I'm sure that borrowing and paraphrasing a few sentences from the javadoc in order to define a term comes under the fair use provision of the copyright law. If you look at the licenses at the bottom of, say, http://java.sun.com/j2se/1.5.0/docs/api/index.html, you'll find no restriction against quotation; the only concern is with redistribution in full.

        To Laura: This is mostly just fine now. Just a few items.

        I don't think the first sentence is needed any more; as Lance said, it's somewhat misleading. (In any case it is missing "for" after "support".)

        Lance's latest request is to remove the sentence beginning "An alternative to the DriverManager facility..." Apparently that's something that should not be in the spec.

        Other than that, it's fine, I think.

        Show
        Kim Haase added a comment - To Dan: I'm sure that borrowing and paraphrasing a few sentences from the javadoc in order to define a term comes under the fair use provision of the copyright law. If you look at the licenses at the bottom of, say, http://java.sun.com/j2se/1.5.0/docs/api/index.html , you'll find no restriction against quotation; the only concern is with redistribution in full. To Laura: This is mostly just fine now. Just a few items. I don't think the first sentence is needed any more; as Lance said, it's somewhat misleading. (In any case it is missing "for" after "support".) Lance's latest request is to remove the sentence beginning "An alternative to the DriverManager facility..." Apparently that's something that should not be in the spec. Other than that, it's fine, I think.
        Hide
        Daniel John Debrunner added a comment -

        from Lance, via Kim:

        "You can borrow from the spec or from the javadoc for DataSource. "

        Errrmmm, can we? What licence is the JDBC spec and Java doc under?
        The ASF (via derby project in this case) needs to follow any licence terms.

        Show
        Daniel John Debrunner added a comment - from Lance, via Kim: "You can borrow from the spec or from the javadoc for DataSource. " Errrmmm, can we? What licence is the JDBC spec and Java doc under? The ASF (via derby project in this case) needs to follow any licence terms.
        Hide
        Laura Stewart added a comment -

        Kim - Would it be acceptable to have this as the text for DataSource:

        The Derby implementation of the DataSource interface provides support the Java Naming and Directory
        Interface (JNDI). A DataSource object is a factory for connections to the physical data source
        that the DataSource object represents. An alternative to the DriverManager facility, a DataSource object is the
        preferred means of getting a connection. An object that implements the DataSource interface will typically be registered
        with a naming service based on the Java Naming and Directory (JNDI) API.
        This allows the calling application to access the database by a name (as a
        data source) instead of through a database connection URL.

        Show
        Laura Stewart added a comment - Kim - Would it be acceptable to have this as the text for DataSource: The Derby implementation of the DataSource interface provides support the Java Naming and Directory Interface (JNDI). A DataSource object is a factory for connections to the physical data source that the DataSource object represents. An alternative to the DriverManager facility, a DataSource object is the preferred means of getting a connection. An object that implements the DataSource interface will typically be registered with a naming service based on the Java Naming and Directory (JNDI) API. This allows the calling application to access the database by a name (as a data source) instead of through a database connection URL.
        Hide
        Laura Stewart added a comment -

        Nope, forgot to change the title of rrefjta16677 in the ditamap. Done now

        One concern that I have with this new wording for DataSource, well, actually 2 concerns:

        1 - It doesn't reflect what Derby implements.
        2 - The term "factory" is not something that I am familiar with... is this standard Java terminology? Will it translate correctly?

        The following comment was from Lance (directly in derby-dev
        in response to a question (shown with >>) from Kim

        ----------------------------------------------------------------------------------------
        On 3/29/07, Lance J. Andersen <Lance.Andersen@sun.com> wrote:
        >
        > > So we are neutral on DriverManager vs. Datasource, and the Working
        > > With Derby example is okay?
        > Yes DriverManager is not going away and is a perfectly acceptable,
        > especially now that u do not have to load the driver explicitly.
        >
        > Ideally to use DataSources in a more portable way outside of an
        > environment which supports JNDI, it would require a Factory so that you
        > do not have to instantiate implementation classes.
        >
        --------------------------------------------------------------------------------------------

        Since I am not that familiar with Java... what I gleen from Lance's comment
        is what we have in the Working with Derby now is okay (leave DriverManager as is)
        ... However, I don't understand the last paragraph of his comment at all
        (it is not clear if we should change WWD and have users use a "Factory",
        whatever that is...)

        Show
        Laura Stewart added a comment - Nope, forgot to change the title of rrefjta16677 in the ditamap. Done now One concern that I have with this new wording for DataSource, well, actually 2 concerns: 1 - It doesn't reflect what Derby implements. 2 - The term "factory" is not something that I am familiar with... is this standard Java terminology? Will it translate correctly? The following comment was from Lance (directly in derby-dev in response to a question (shown with >>) from Kim ---------------------------------------------------------------------------------------- On 3/29/07, Lance J. Andersen <Lance.Andersen@sun.com> wrote: > > > So we are neutral on DriverManager vs. Datasource, and the Working > > With Derby example is okay? > Yes DriverManager is not going away and is a perfectly acceptable, > especially now that u do not have to load the driver explicitly. > > Ideally to use DataSources in a more portable way outside of an > environment which supports JNDI, it would require a Factory so that you > do not have to instantiate implementation classes. > -------------------------------------------------------------------------------------------- Since I am not that familiar with Java... what I gleen from Lance's comment is what we have in the Working with Derby now is okay (leave DriverManager as is) ... However, I don't understand the last paragraph of his comment at all (it is not clear if we should change WWD and have users use a "Factory", whatever that is...)
        Hide
        Kim Haase added a comment -

        Thanks, Laura – These look excellent.

        However, I have since gotten more feedback from Lance (between ===):

        ====
        The page is not consistent as it should just describe what a DataSource is to align with what it states for the other interfaces.

        You can borrow from the spec or from the javadoc for DataSource.

        The problem i have with the wording, is you can use a DataSource without JNDI and it can (and typically is) looked up as a resource via JNDI.

        Also need to migrate to referring to Java EE vs J2EE as well.
        ===

        The last bit can wait, but we may as well reword the description based on the javadoc. Here is some text that can replace the first two sentences. I think the last sentence ("This allows the calling application to access the database by a name (as a data source) instead of through a database connection URL.") can stay as is.

        "A DataSource object is a factory for connections to the physical data source that the DataSource object represents. An alternative to the DriverManager facility, a DataSource object is the preferred means of getting a connection. An object that implements the DataSource interface will typically be registered with a naming service based on the Java(TM) Naming and Directory (JNDI) API."

        Interesting in view of the fact that our Working With Derby example uses DriverManager; at some point perhaps it should be changed to use DataSource, but that is yet another task.

        BTW, did you also change the title of rrefjta16677.dita in the map file?

        Show
        Kim Haase added a comment - Thanks, Laura – These look excellent. However, I have since gotten more feedback from Lance (between ===): ==== The page is not consistent as it should just describe what a DataSource is to align with what it states for the other interfaces. You can borrow from the spec or from the javadoc for DataSource. The problem i have with the wording, is you can use a DataSource without JNDI and it can (and typically is) looked up as a resource via JNDI. Also need to migrate to referring to Java EE vs J2EE as well. === The last bit can wait, but we may as well reword the description based on the javadoc. Here is some text that can replace the first two sentences. I think the last sentence ("This allows the calling application to access the database by a name (as a data source) instead of through a database connection URL.") can stay as is. "A DataSource object is a factory for connections to the physical data source that the DataSource object represents. An alternative to the DriverManager facility, a DataSource object is the preferred means of getting a connection. An object that implements the DataSource interface will typically be registered with a naming service based on the Java(TM) Naming and Directory (JNDI) API." Interesting in view of the fact that our Working With Derby example uses DriverManager; at some point perhaps it should be changed to use DataSource, but that is yet another task. BTW, did you also change the title of rrefjta16677.dita in the map file?
        Laura Stewart made changes -
        Attachment derby1934_html2.zip [ 12354553 ]
        Attachment derby1934_2.diff [ 12354552 ]
        Hide
        Laura Stewart added a comment -

        Attached is the lastest patch and a zip file containing the html of the 3 files.

        I updated the 3 files you mentioned.
        Additionally, I updated the ditamap to reflect the change to the name of rrefjta18596.dita to show "Interfaces" and not "Extensions".
        Finally, there were a few files that contained a line "Arbortext..." which is a line added by my editor. So I updated these files to remove the line.

        Show
        Laura Stewart added a comment - Attached is the lastest patch and a zip file containing the html of the 3 files. I updated the 3 files you mentioned. Additionally, I updated the ditamap to reflect the change to the name of rrefjta18596.dita to show "Interfaces" and not "Extensions". Finally, there were a few files that contained a line "Arbortext..." which is a line added by my editor. So I updated these files to remove the line.
        Hide
        Kim Haase added a comment -

        I now realize that if we fix this file, we also need to fix:

        rrefjta16677.dita: Change title from "J2EE Compliance: Java Transaction API and javax.sql Extensions" to "J2EE Compliance: Java Transaction API and javax.sql Interfaces", and change "extension" to "interface" throughout.

        Change the link from

        http://java.sun.com/j2ee/docs.html

        to

        http://java.sun.com/javaee/reference/

        and give it the scope="external" attribute.

        rrefjta94396.dita: Remove the following sentence:

        The JDBC 2.0 standard extension binaries are available from http://java.sun.com/products/jdbc/download.html.

        Show
        Kim Haase added a comment - I now realize that if we fix this file, we also need to fix: rrefjta16677.dita: Change title from "J2EE Compliance: Java Transaction API and javax.sql Extensions" to "J2EE Compliance: Java Transaction API and javax.sql Interfaces", and change "extension" to "interface" throughout. Change the link from http://java.sun.com/j2ee/docs.html to http://java.sun.com/javaee/reference/ and give it the scope="external" attribute. rrefjta94396.dita: Remove the following sentence: The JDBC 2.0 standard extension binaries are available from http://java.sun.com/products/jdbc/download.html .
        Hide
        Kim Haase added a comment -

        Hi, Laura – I wrote to Lance asking him to comment. I'm not sure if he will do so directly, but he did say, "These old optional packages are part of JDBC as of JDBC 3.0 so they are not optional." So it is probably better to point people to http://java.sun.com/javase/reference/api.jsp – these interfaces are all part of the API documentation for all Java releases starting with 1.4.

        So "extension" is an obsolete term now, and "interface" is the more accurate term. If you look at http://java.sun.com/j2se/1.4.2/docs/api/, for instance, and click javax.sql in the top left window, you will see in the bottom window that DataSource, ConnectionPoolDataSource, PooledConnection, and XADataSource are all interfaces.

        Technically any package that starts with "javax" instead of plain "java" is an extension, but you can see that many such packages are an integral part of the Java platform, and we don't usually use the term "extension" to describe them any more. It is true that the javax.sql interfaces support the J2EE platform (which has now changed its name to "Java EE", actually, but let's not worry about that at this point).

        Show
        Kim Haase added a comment - Hi, Laura – I wrote to Lance asking him to comment. I'm not sure if he will do so directly, but he did say, "These old optional packages are part of JDBC as of JDBC 3.0 so they are not optional." So it is probably better to point people to http://java.sun.com/javase/reference/api.jsp – these interfaces are all part of the API documentation for all Java releases starting with 1.4. So "extension" is an obsolete term now, and "interface" is the more accurate term. If you look at http://java.sun.com/j2se/1.4.2/docs/api/ , for instance, and click javax.sql in the top left window, you will see in the bottom window that DataSource, ConnectionPoolDataSource, PooledConnection, and XADataSource are all interfaces. Technically any package that starts with "javax" instead of plain "java" is an extension, but you can see that many such packages are an integral part of the Java platform, and we don't usually use the term "extension" to describe them any more. It is true that the javax.sql interfaces support the J2EE platform (which has now changed its name to "Java EE", actually, but let's not worry about that at this point).
        Laura Stewart made changes -
        Derby Info [Patch Available]
        Hide
        Laura Stewart added a comment -

        Hi Kim - I was hoping you would lend your expertise to this issue Thanks for your comments.
        For the last sentence, you refer to DataSource as an interface... the section is about extensions.
        Which is more accurate?

        Show
        Laura Stewart added a comment - Hi Kim - I was hoping you would lend your expertise to this issue Thanks for your comments. For the last sentence, you refer to DataSource as an interface... the section is about extensions. Which is more accurate?
        Hide
        Kim Haase added a comment -

        Uh-oh, we've got colliding JIRAs. DERBY-2090 (fixed recently) was actually a duplicate of this issue, I believe, but we didn't catch this. Which solution is preferable? The thing is, the JDBC 2.0 Optional Package API is very old – that API has been folded into the JDK for some time (it is part of JDK 1.4.2 and every JDK since). So I would suggest that the current wording –

        "(For more details about these extensions, see the API documentation for your version of the Java Development Kit, which you can find at http://java.sun.com/javase/reference/api.jsp)."

        may be preferable. Lance Andersen may be the best authority on which reference to use.

        I agree that the following sentence is ambiguous:

        "Derby's implementation of DataSource means that it supports JNDI; as a resource manager, it allows a database to be named and registered within a JNDI server."

        I think that "it" means "Derby" in the first clause and "DataSource" in the second. Maybe it could be rephrased as follows:

        "By implementing DataSource, Derby provides support for the Java Naming and Directory Interface (JNDI). As a resource manager, the Datasource interface allows ..."

        Show
        Kim Haase added a comment - Uh-oh, we've got colliding JIRAs. DERBY-2090 (fixed recently) was actually a duplicate of this issue, I believe, but we didn't catch this. Which solution is preferable? The thing is, the JDBC 2.0 Optional Package API is very old – that API has been folded into the JDK for some time (it is part of JDK 1.4.2 and every JDK since). So I would suggest that the current wording – "(For more details about these extensions, see the API documentation for your version of the Java Development Kit, which you can find at http://java.sun.com/javase/reference/api.jsp )." may be preferable. Lance Andersen may be the best authority on which reference to use. I agree that the following sentence is ambiguous: "Derby's implementation of DataSource means that it supports JNDI; as a resource manager, it allows a database to be named and registered within a JNDI server." I think that "it" means "Derby" in the first clause and "DataSource" in the second. Maybe it could be rephrased as follows: "By implementing DataSource, Derby provides support for the Java Naming and Directory Interface (JNDI). As a resource manager, the Datasource interface allows ..."
        Laura Stewart made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Laura Stewart made changes -
        Attachment derby1934_1.diff [ 12354339 ]
        Attachment rrefjta18596.html [ 12354340 ]
        Hide
        Laura Stewart added a comment -

        Attaching a patch and html file for this issue.

        There are several places in the text where "it" is used. This can be ambiuous.
        Does "it" refer to Derby or to the extension?

        Please clarify if you can.

        Show
        Laura Stewart added a comment - Attaching a patch and html file for this issue. There are several places in the text where "it" is used. This can be ambiuous. Does "it" refer to Derby or to the extension? Please clarify if you can.
        Laura Stewart made changes -
        Assignee Laura Stewart [ scotsmatrix ]
        Andrew McIntyre made changes -
        Fix Version/s 10.3.0.0 [ 12310800 ]
        Fix Version/s 10.2.3.0 [ 12312215 ]
        Hide
        Andrew McIntyre added a comment -

        Unsetting Fix Version for unassigned issues.

        Show
        Andrew McIntyre added a comment - Unsetting Fix Version for unassigned issues.
        Rick Hillegas made changes -
        Field Original Value New Value
        Fix Version/s 10.2.2.0 [ 12312027 ]
        Fix Version/s 10.2.3.0 [ 12312215 ]
        Hide
        Rick Hillegas added a comment -

        Reassigning to 10.2.3.0.

        Show
        Rick Hillegas added a comment - Reassigning to 10.2.3.0.
        Laura Stewart created issue -

          People

          • Assignee:
            Laura Stewart
            Reporter:
            Laura Stewart
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development