Hi Ward,
Thanks a lot for your patch.
Can you please open an issue in JIRA for this so that we can track it. You can use the following URL for creating a new issue:
http://opensource.atlassian.com/projects/xdoclet/secure/CreateIssue!default.jspa
I will look at your patch as soon as it is in JIRA. ;-)
Regards, Matthias
Ward, Tyler schrieb:
The alterations have been completed. I am attaching the value-object xdt (xdoclet-ejb-module-1.2.2.jar/xdoclet/modules/ejb/entity/resources/valueobject.xdt). Will one of the maintainers look it over and include it in the CVS repository, unless there are any objections.
If there are any objections, please bring them to my attention and I'll try to fix the problems. This inclusion is needed, as we are trying to use value objects, but they are a little too incomplete for us to use in their current form, and we don't want to branch XDoclet. It doesn't appear that these are too widely used yet (otherwise there would be more complaints about their problems), so hopefuly these changes won't bother anyone.
<<valueobject.xdt>> No further changes should be needed to use the upgrded value objects.
Thank You,
-Tyler
-----Original Message-----
From: Ward, Tyler Sent: Tuesday, March 01, 2005 10:09 AM
To: 'xdoclet-devel@lists.sourceforge.net'
Subject: value object alterations...
I noticed that the value objects produced by ejbDoclet (1.2.2) appear to be about half completed. I took the liberty of producing a more complete version, and wonder if you guys would like to include my patch. Basically, here are my changes.
1) Added a new method that returns an unmodifiable collection (or set) for the relationships. get*Collection(). This prevents the users from needing to produce an array every time they want to use the values of that relationship. I did not remove the array based methods, for compatibility, but perhaps they are not needed.
2) Changed the getAdded*s(), etc... methods to return unmodifiable collections, outsiders shouldn't be adjusting those sets. We might also want to remove the setAdded*s(Set|Collection) methods, as once again, outsiders shouldn't be adjusting those.
3) Added three "synchronization" options. a) "None": Nothing is synchronized.
b) "Partial": Collections become Collections.synchronized[Collection|Set](...). This is needed because the unmodifiable collections can easily end up in different threads, and are not likely to be consistent when viewed from other threads if the underlying collection is not synchronized. c) "Full": All collections are synchronized. All methods are synchronized.
The default is "Partial". In most cases, even the "full" option should not allow for deadlock unless the .hashCode(), .equals() or .compareTo() methods of the inner objects acquire contended locks during the course of normal operation. This would allow a deadlock in a synchronized collection. I plan to use "full" for my project (unless a compelling performance problem is encountered) for safety. I would be willing to make the default "none", but that seems unnecessarily dangerous, and for very little gain.
4) Add two "ordering" options. a) "Strict": The object extends comparable. Primary key equality determines object equality/hashCode/Comparison. Primary key fields must be comparable.
b) "Permissive": The objects are compared on all fields. Values do not extend Comparable (basically, how it was before).
The default is "Permissive".
5) Value objects now correctly implement Cloneable.
6) Value objects now also have a read-only wrapper inner class that can be returned. It includes all the getters, but none of the setters. I'm thinking of having it be comparable if the Value object is comparable, cloneable (which will just make another wrapper around the same Value object), and overriding .equals and .hashCode for it. As well as making it serializable.
Do all these changes seem reasonable? If there are any modifications requested, let me know and I'll modify the .xdt to include them. If people like this idea, then I'll comment up the .xdt a little more, and submit it.
-Tyler
This e-mail message is intended only for the named recipient(s) above. It may contain confidential information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you.
-- Matthias Germann <[EMAIL PROTECTED]>
------------------------------------------------------- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click _______________________________________________ xdoclet-devel mailing list xdoclet-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
