Revision as of 21:20, 4 November 2009 by Admin (Talk | contribs)
(diff) ← Older revision | Current revision (diff) | Newer revision → (diff)

Review page for JNDI Context Re-architecture

This page is used to manage the review of the spec for JNDI Context Re-architecture .

The value of this approach is that it allows me to track all the issues separately and to drive them to resolution. For me email reviews although nice and informal are almost impossible to track to conclusion. Inline comments to the main document muddy up the document and are also difficult to track to conclusion.

The review process works like this:

  • Add a comment header of the format "Comment <initials>-<number> (<status>)" (see below for examples)
  • A discussion then can take place under that comment header
  • Each comment will have a status at the top, with the status set to Approved, Accepted PDU (pending doc update) or Unresolved
  • If necessary, we do more rounds of discussion until the item is marked as Approved


Commenter Initials Key



This is an example comment


A general comment, I had a really hard time following the design. I know part of it is because I'm a newbie, but other folks who don't know this area well may also need to understand this design. I give some ideas below that I think would help me (and maybe others) grok this better.


A Designtime Naming Context implementation serves as the service data source name to the corresponding database connection information via the DatasourceManager - I'm not sure I understand what "serves as the service data source name" means...


In the Background and Proposed Changes section, there are quite a number of concepts/names showing up, all of which have various associations and inter-relationships. It would really help me, and I suspect others reviewing this to have some pictures. In particular, a UML-like diagram showing all the concepts/classes/components and their relationships with each other would be invaluable.


For the sake of QE, docs, etc., a clear distinction is needed between user-visible functional behavior changes and the internal design. For instance, Use Cases is really part of the functional behavior, but it's at the bottom and not clearly marked as part of a functional spec vs. design spec.


I have an idea what you mean by "context" and "context factory", but I'm not sure. Can you provide a definition?


The project will be stored as part of the context. Don't you mean the context will be stored as part of the project?

JWB - no, a context will contain a reference to the project. A Project instance will not contain a reference to the context. See the example source for DesignTimeDatasourceContext


In the drilldown section, it would help me if you worked through the key use cases and showed how all the classes/components interact with each other as you exercise the use case. You describe the changes to classes and such, but it's hard to figure out how these changes are used and why they're needed.


What is the "initialize-on-demand holder class idiom"? I see an example of it, but perhaps you can describe it in a sentence.


Under Use Cases: Result: the data source name will be used for the data source name in myFourthNewProject - I don't understand this.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo