[Xdoclet-devel] [XDoclet-JIRA] Created: (XDT-1289) Orion cmp-mapping uses wrong tag for sql-type
Message: A new issue has been created in JIRA. - View the issue: http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1289 Here is an overview of the issue: - Key: XDT-1289 Summary: Orion cmp-mapping uses wrong tag for sql-type Type: Bug Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: XDoclet Components: Orion Module Versions: 1.3 Assignee: xdoclet-devel (Use for new issues) Reporter: David Croft Created: Thu, 3 Mar 2005 7:15 AM Updated: Thu, 3 Mar 2005 7:15 AM Description: orion cmp-mapping is looking at @orion.persistence for sql-type whereas this field is in fact on @ejb.persistence Here is the patch against CVS to fix. I don't imagine this will affect backwards-compatibility as orion currently seems to ignore persistence-type="" --- orion-cmp-mapping.xdt 18 Mar 2003 22:21:17 - 1.7 +++ orion-cmp-mapping.xdt 3 Mar 2005 13:12:16 - @@ -22,7 +22,7 @@ persistence-name="" - + persistence-type="" > - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/xdoclet/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ xdoclet-devel mailing list xdoclet-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] [XDoclet-JIRA] Commented: (XDT-1288) @weblogic.dispatch-policy doesnt generate an entry in weblogic-ejb-jar.xml
The following comment has been added to this issue: Author: max ashton Created: Thu, 3 Mar 2005 9:14 AM Body: SORRY GUYS forget about this. i am new to xdoclet. sorted it out now. I think more xdoclet feedback would be welcome to hep newbies like me when running ant's ebjdoclet task. - View this comment: http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1288?page=comments#action_16080 - View the issue: http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1288 Here is an overview of the issue: - Key: XDT-1288 Summary: @weblogic.dispatch-policy doesnt generate an entry in weblogic-ejb-jar.xml Type: Bug Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: XDoclet Components: Bea Module Versions: 1.2.2 Assignee: xdoclet-devel (Use for new issues) Reporter: max ashton Created: Wed, 2 Mar 2005 10:53 AM Updated: Thu, 3 Mar 2005 9:14 AM Description: the dispatch-policy is not appearing in weblogic-ejb-jar.xml when i use @weblogic.dispatch-policy="MyExecuteQueue" also @weblogic.enable-call-by-reference="True" doesn't put an entry in that file. am i doing something wrong?? - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/xdoclet/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ xdoclet-devel mailing list xdoclet-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] [XDoclet-JIRA] Closed: (XDT-1288) @weblogic.dispatch-policy doesnt generate an entry in weblogic-ejb-jar.xml
Message: The following issue has been closed. Resolver: Matthias Germann Date: Thu, 3 Mar 2005 10:14 AM You can post to the Xdoclet-user mailing list (http://xdoclet.sourceforge.net/xdoclet/mail-lists.html) if you have questions on how to use xdoclet. - View the issue: http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1288 Here is an overview of the issue: - Key: XDT-1288 Summary: @weblogic.dispatch-policy doesnt generate an entry in weblogic-ejb-jar.xml Type: Bug Status: Closed Priority: Major Resolution: CANNOT REPRODUCE Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: XDoclet Components: Bea Module Versions: 1.2.2 Assignee: xdoclet-devel (Use for new issues) Reporter: max ashton Created: Wed, 2 Mar 2005 10:53 AM Updated: Thu, 3 Mar 2005 10:14 AM Description: the dispatch-policy is not appearing in weblogic-ejb-jar.xml when i use @weblogic.dispatch-policy="MyExecuteQueue" also @weblogic.enable-call-by-reference="True" doesn't put an entry in that file. am i doing something wrong?? - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/xdoclet/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ xdoclet-devel mailing list xdoclet-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
[Xdoclet-devel] New Value Object
It seems that the ejb value objects are somewhat incomplete. Therefore, I have taken it upon myself to do some work on them. There are a few flaws that I see in the value objects now. 1) No synchronization. It is likely that under some situations it would be nice to be able to turn on synchronization. 2) Returning bare collections. We should return unmodifiable collections to force less error prone code. 3) Synchronized collections should be an option, once again, to reduce the dangers of multi threaded code. 4) Should implement Cloneable. 5) Implement Comparable? 6) Should not use arrays to pass around relationship data, the construction and deconstruction of arrays is inefficient, especially for large numbers of arrays. 7) Should not allow outside access to setAdded*s(), and other bookkeeping collections. As a result, I made the following changes. 1) implemented Comparable. 2) Added an "ordering" class level option. a) ordering = "strict", ordering/equality/hashCode is only dependant on the primary key of the object. Object implements Comparable if and only if all primary key fields are Comparable. b) ordering = "permissive". equality/hashCode based on all fields, but not relationships. c) default is "permissive" 3) Added "synchronization" class level option. a) synchronizaton = "none": same as before. a) synchronization = "partial": all [Collection|Set]s become Collections.synchronized[Collection|Set](); a) synchronization = "full": Same as "partial", but all methods synchronized as well. 4) All returned [Collection|Set]s are Collections.unmodifiable[Collection|Set](...). 5) Added get*Collection() method that returns unmodifiable [Collection|Set] of the relations. In the future, we may wish to remove a few of the more dangerous methods. Also, the EJB (CMP) template should automatically create properly named get*Value() and set*Value(*Value input) methods without requiring the addition of them into the Bean class, if it is abstract. Have an option to make the ejbCreate(*Value input) and ejbPostCreate(*Value input) method as well, if bean class is abstract. What do you all think? Any suggestions? -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.
Re: [Xdoclet-devel] New Value Object
On Thu, 2005-03-03 at 21:17, Ward, Tyler wrote: > As a result, I made the following changes. > ... > 4) All returned [Collection|Set]s are > Collections.unmodifiable[Collection|Set](...). > 5) Added get*Collection() method that returns unmodifiable [Collection|Set] > of the relations. UnmodifiableCollection is part of the Apache commons-collections library, isn't it? I don't think we should introduce dependencies on third-party libraries in generated code, unless it's optional (e.g. a config parameter or @ejb.value-object use-unmodifiable-collections="true" parameter, defaulting to false). For some things it's appropriate (it's a no-brainer that the Struts jar is required to compile generated Struts form beans), but while we might use commons-collections to run XDoclet that doesn't mean we should force people to use it to compile their own (and generated) code. Andrew. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ xdoclet-devel mailing list xdoclet-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
Re: [Xdoclet-devel] New Value Object
IMHO, he would like to use the java.util.Collections class to get unmodifiable Collections and not the commons-collections library. Regards, Mathhias Andrew Stevens schrieb: On Thu, 2005-03-03 at 21:17, Ward, Tyler wrote: As a result, I made the following changes. ... 4) All returned [Collection|Set]s are Collections.unmodifiable[Collection|Set](...). 5) Added get*Collection() method that returns unmodifiable [Collection|Set] of the relations. UnmodifiableCollection is part of the Apache commons-collections library, isn't it? I don't think we should introduce dependencies on third-party libraries in generated code, unless it's optional (e.g. a config parameter or @ejb.value-object use-unmodifiable-collections="true" parameter, defaulting to false). For some things it's appropriate (it's a no-brainer that the Struts jar is required to compile generated Struts form beans), but while we might use commons-collections to run XDoclet that doesn't mean we should force people to use it to compile their own (and generated) code. Andrew. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ xdoclet-devel mailing list xdoclet-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xdoclet-devel -- Matthias Germann <[EMAIL PROTECTED]> --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ xdoclet-devel mailing list xdoclet-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
