• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

URLy Bird 1.1.2 - Clarification on 4 items

 
Arun G Rao
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Greetings,

I downloaded my exam last week. Can somebody please clarify the followig.

1) RecordNo.
There are methods that takes in RecordNo as the parameter in the Data class. Since there is no RecordNo field in the schema, Can I asusme that the recordNo refers to the location of the record in the file. For e.g the first record is RecordNo = 1, second record = 2 and so on.

2) Use of generics
Is there a penalty for NOT using generics. I am using JDK 1.5.

3) Log File location
a) I am thinking of using Logger and generate the logs to the C:\ drive. Is this acceptable or should I generate the logs file to the folder where the JAR is stored.
b) Should the log file be overwritten for each new execution or should be append to the logs.

4) LockCookie
How do I generate a LockCookie? What is the correlation of a lockCookie with the recordNumber.

Thanks in advance for your help.

Happy Holiday!

Arun
 
Martin Sturzenhecker
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Arun,

welcome to the ranch greenhorn

Ad 1: Exactly.

Ad 2: Generally I don't think there is such a penalty. My spec (URLyBird 1.1.3) has a section called "Use of Standard Elements" which states:

Use of functionality provided by the core Java classes will be preferred to your own implementation of that functionality, unless there is a specific advantage to providing your own implementation.


Having such a section one may argue not using generics violates this rule; yet I don't believe they are so picky.

Ad 3a: Be sure to not introduce any platform dependcies here. "C:\" won't exit on a linux, mac os x, solaris machine. I'd prefer using a "tmp" dir, the current working dir or the user home dir.

Ad 3b: I use several rotating files, 64kB each.

Ad 4: You can generate the cookies as you like. Some strategies may be:
  • Always use the same value.
  • Use a counter.
  • Use the record number.
  • Generate a (pseudo) random long.
  • Somehow "entangle" the record number, a client id and maybe a random number.
  • <your own strategy goes here>

  • The first three attempts are easy to guess, so clients with a bad attitude may grab the lock on a record although they do not own it.

    -martin
     
    Arun G Rao
    Greenhorn
    Posts: 14
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks much Martin.

    Regarding 3b) Should I maintain a log.xml or some properties file to have settings like location, size of the logs, granularity of the logs, format etc..

    Which brings to my next question

    Should we provide a UI for all such settings because it is clearly stated that the assessor will not modify any file. More importantly, Should we provide a UI for DB file location and persist it?

    Arun
     
    Martin Sturzenhecker
    Greenhorn
    Posts: 23
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Arun,

    Originally posted by Arun G Rao:

    Regarding 3b) Should I maintain a log.xml or some properties file to have settings like location, size of the logs, granularity of the logs, format etc..

    Which brings to my next question

    Should we provide a UI for all such settings because it is clearly stated that the assessor will not modify any file. More importantly, Should we provide a UI for DB file location and persist it?


    I configure logging using a properties file which I deliver within runme.jar. There is no way to configure logging in my application apart from that. But one must implement a way to set file location (host + path) and persist that setting. A few days ago Andrew Monkhouse replied to a thread with very much the same problem.

    -martin
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic