Simon Cockayne

Hi,

What happened to Xdoclet?

I see the page on sourcefourge http://xdoclet.sourceforge.net/xdoclet/index.html has not been updated since May 2005.

And...home page of XDoclet2 http://xdoclet.codehaus.org/ appears to have had no release since 2005.

Is this a dead technology?

Cheers,

Simon

Hi Liviu,

Give it a whirl!

Simon

Mike,

Ok...client calls createRecord().

createRecord calls lock ( on a deleted record) > insert data > mark as UNdeleted > unlock.

But..according to the spec...lock on a deleted record should throw recordnotfoundexception.

Si

Mike,

I hear what you are saying.

But regardless of whether you expose or hide the methods in the data access class at a higher level...the data access class Data.java MUST implement the interface.

And the interface description says RecordNotFoundException should be thrown if the record is not found or is deleted.

Si

Mike,

What about the case where create() wants to reuse a deleted record?

Surely then you would want to lock the deleted record first, to make sure that two clients aren't both trying to reuse the deleted record?

Simon

Jar et al,

Ok I have had a revelation.

I cannot use lock/unlock properly with deleted records if I keep to the assignment spec.

So...I'll just also create lockDeletedRecord() and unlockDeletedRecord().

I mean the assignment spec does not say..."You have to use the lock() and unlock() methods in the interface for ALL your locking needs".

Si

Jar,

Here's another anomaly.

Lock should throw RecordNotFoundException on a deleted record.

But if that is the case, how can you reuse a deleted record (possibly required by create())? Surely the deleted record to be reused should be locked before it is reused, but any attempt to lock it with lock() should throw RecordNotFoundException!

Simon

Hi Jar,

I went to sleep thinking about the delete method and I woke up thinking about the delete method.

(I take comfort in the fact that at least I didn't dream about the deleted method).

I see that you are saying since you do not allow lock() to lock a deleted method then unlock() would never have to unlock a deleted record.


That's fine...EXCEPT...what if the client DOES call unlock() on a deleted record? The assignment says you SHOULD throw RecordNotFoundException in this case and you are not doing that...

Cheers,

Simon

Hi Jeroen,

Can you "support"/"prove" your indenting suggestion with a Sun standard?

I tried applying Sun's coding standards... http://java.sun.com/docs/codeconv/html/CodeConventions.doc3.html#248)
...to Mike's example and it 'aint so pretty. :-)

Yours does look nice, but you're not indenting 8 spaces...so I was wondering how you got to what you got.

Cheers,

Simon

Hi all,

My assignment states:

"Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file."

When deleting a record a typical client might expect to:
lock() the record, delete() the record and then unlock() the record.

But according to the "API", unlock() should throw RecordNotFoundException because by that time my record IS marked deleted.

Thoughts?

Simon

Keith,

I expect you can...but you would probably get a low mark. This is my personal opnion based on no evidence.

More importantly though...a poorly designed solution...moreover lacking the ability to design a solution that is not poor...is not going to stand one in good stead with an employer hiring one based on SCJD.


But...there is no reason to have to submit a poorly designed solution.

There is a wealth of material of how to do good design. Lot's of best practices...patterns...common approaches et cetera.


Follow in the footsteps of others!



I'll shut up now and let someone who knows what they are talking about speak.

Si

I use Eclipse.

It is ace.

Si

Keith,

The Andrew Monkhouse book is pretty specific to SCJD...and does map closely to what you will need to do for this certification.


Whereas the Head First Patterns book covers OO design in general, through the medium of Patterns and it really, really, makes you think. It's well written with good examples (actually pretty funny in places too).

I reckon it is a surefire certainty that you would be a better designer for reading the patterns book.

Cheers,

Si.

Monkhouse

Keith,

BTW - if you want to read a good book on OO design principles read "Head First Design Patterns"...it rocks.


Also, take comfort that there is no time limit for the assignment...so you have got plenty of time to learn what you need to learn.

Simon