From: Rupp, H. <Hei...@ce...> - 2004-10-18 18:10:57
|
As far as I recall are all Collection classes fully qualified. =20 There was report some time ago about this behaviour, but I think it is = solved. =20 Hm. Can you show your input? ________________________________ Von: xdo...@li... im Auftrag von Gemar, = Edward Gesendet: Mo 18.10.2004 18:24 An: xdo...@li... Betreff: [Xdoclet-user] Collection class not imported - VO's won't = compile Hi all, I've just upgraded to 1.2.2rc1 from 1.2b2 (for hibernate = support) and now my EJB value objects won't compile because the = Collection class isn't imported. This issue was brought up in April, = but I haven't seen a JIRA against it and it's obviously a problem in = latest release candidate. This is a major issue for us that breaks the = build. Any ideas or workarounds? Thanks, Edward From: Lars Rohleder <l@ta...> Re: AW: Bug in xDoclet 1.2 final? =20 2004-04-16 00:29 Well, in version 1.2 (final) java.util.Collection doesn"t get imported nor is this class fully qualified in my value objects. And on JIRA I can"t find the bug (today JIRA seems to work). Lars On Thu, 2004-04-15 at 22:19, Rupp, Heiko wrote: > There is an item in Jira open wrt. this. > The current CVS version fully qualifies the collections as > java.util.Collection and does > not need the import. > I can"t really comment on 1.2 though. >=20 > Heiko > > = ______________________________________________________________________ > Von: xdoclet-user-admin@li... im Auftrag von Lars > Rohleder > Gesendet: Do 15.04.2004 21:19 > An: xdoclet-user@li... > Betreff: [Xdoclet-user] Bug in xDoclet 1.2 final? > > > > Hi folks, > > I couldn"t find anything on the web or on this mailing list relating > this topic so I hope this hasn"t been asked earlier. > > After updating from xdoclet1.2b3 to xdoclet1.2 our project can"t be > compiled any more. It seems that the abstract value objects generated > from our entity beans are missing the import statement for > java.util.*. > Since we"re using collections I get a lot of error messages from ant. > > Using beta3 still works, 1.2.0 doesn"t. > I don"t think the taskdef or path definitions in our build.xml are > wrong. I didn"t change anything and upgrading to version 1.2.0 was > done > through changing the symbolic link to xdoclet to the new directory. > (And > of course I use this link in ant too.) > > Any suggestions? > > Lars > > > By the way: Where can I post bugs? Neither bug tracker on > SourceForge.net (closed) nor JIRA (error 404) will work. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > = administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck > _______________________________________________ > xdoclet-user mailing list > xdoclet-user@li... > https://lists.sourceforge.net/lists/listinfo/xdoclet-user > > > ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give = us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out = more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ xdoclet-user mailing list xdo...@li... https://lists.sourceforge.net/lists/listinfo/xdoclet-user |
From: Gemar, E. <Edw...@zi...> - 2004-10-18 19:45:49
|
Here is the input. Again, this works fine with xdoclet 1.2b2, but under 1.2.2rc1 the value object won't compile due to a missing import for Collection. Needless to say, the Collection class is *not* fully qualified in the VO generated for this class by 1.2.2r1. We would very much like to use the latest version of xdoclet for hibernate support purposes, but this issue currently has us dead in the water since our VOs will no longer compile. The only thing I saw regarding this was this entry in the changelog. Does this mean that the Collection class must be fully qualified in my bean now? This would be unfortunate as it would break xdoclet 1.2+ backwards compatibility with previous versions. 2004-04-21 09:23:14 Heiko Rupp modules/ejb/src/META-INF/xtags.xml <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xdoclet/xdoclet/modules/ ejb/src/META-INF/xtags.xml> v 1.43 <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xdoclet/xdoclet/modules/ ejb/src/META-INF/xtags.xml?rev=3D1.43&content-type=3Dtext/vnd.viewcvs= -ma rkup> =20 Update documentation of @ejb.value-object wrt. type of possible Collection types. Especially that those need to be fully qualified. After a suggestion from Lars Rohleder [l.rohleder at tallence.de] Any insight is greatly appreciated. Thanks. =20 Edward =20 =20 Input: =20 package com.foo.management.alerts; =20 import com.foo.utils.logging.Logger; import javax.ejb.*; import java.util.*; =20 /** * Describes a set of levels that can be alerted on. Basically acts as * a container of {@link AlertLevelLocal} that can be chosen from the * interface when creating an alert rule. * * @version 1.0 05/10/2004 * * @zpm:genall * * @ejb.bean name=3D"AlertLevelSet" * local-jndi-name=3D"zpm_management_ejb_AlertLevelSet" * type=3D"CMP" * cmp-version=3D"2.x" * view-type=3D"local" * primkey-field=3D"iD" * * @ejb.persistence table-name=3D"rep_meta_alertLevelSet" * @jboss.container-configuration name=3D"ZPM Cached CMP EntityBean" * @jboss.persistence create-table=3D"false" remove-table=3D"false" * * @ejb.finder * signature=3D"java.util.Collection findAll()" * query=3D"SELECT OBJECT(r) FROM AlertLevelSet AS r" * * @ejb.transaction type=3D"Required" * @ejb.value-object name=3D"AlertLevelSet" match=3D"*" * @ejb.util generate=3D"physical" */ abstract public class AlertLevelSetBean implements EntityBean { private static final String CLASS_NAME =3D AlertLevelSetBean.class.getName(); private static final Logger logger =3D Logger.getLogger(CLASS_NAME); =20 /** * @ejb.persistence column-name=3D"setID" * @ejb.pk-field */ abstract public Integer getID(); abstract public void setID(Integer id); =20 /** * @return String display name of the level * * @ejb.persistence column-name=3D"displayName" * @ejb.interface-method */ abstract public String getDisplayName(); /** @ejb.interface-method */ abstract public void setDisplayName(String name); =20 /** * @return int sort order for display purposes * * @ejb.persistence column-name=3D"sortOrder" * @ejb.interface-method */ abstract public int getSortOrder(); /** @ejb.interface-method */ abstract public void setSortOrder(int order); =20 /** * @ejb.relation name=3D"AlertLevelSet-AlertLevel" * role-name=3D"AlertLevelSet-hasN-AlertLevels" * target-role-name=3D"AlertLevel-BelongsToMany-AlertLevelSets" * target-ejb=3D"AlertLevel" * target-cascade-delete=3D"no" * target-multiple=3D"yes" * * @ejb.value-object compose=3D"com.foo.management.alerts.AlertLevelVO" * compose-name=3D"Level" * members=3D"com.foo.management.alerts.AlertLevelLocal" * members-name=3D"AlertLevelVO" * relation=3D"external" * type=3D"Collection" * * @jboss.relation related-pk-field=3D"iD" * fk-column=3D"levelID" * @jboss.target-relation related-pk-field=3D"iD" * fk-column=3D"setID" * @jboss.relation-mapping style=3D"relation-table" * @jboss.relation-table table-name=3D"rep_meta_alertLevelSetToLevel" * create-table=3D"false" * remove-table=3D"false" * row-locking=3D"false" * @ejb.interface-method */ abstract public Collection getLevels(); /** @ejb.interface-method */ abstract public void setLevels(Collection levels); =20 =20 =20 /** * @ejb.create-method view-type=3D"local" */ public Integer ejbCreate(AlertLevelSetVO set) throws CreateException { setID(set.getID()); setDisplayName(set.getDisplayName()); setSortOrder(set.getSortOrder()); return null; } =20 /** * trying post create for setting the vo since we have relations... */ public void ejbPostCreate(AlertLevelSetVO set) throws CreateException { setAlertLevelSetVO(set); } =20 /** @ejb.interface-method */ public abstract AlertLevelSetVO getAlertLevelSetVO(); =20 /** @ejb.interface-method */ public abstract void setAlertLevelSetVO(AlertLevelSetVO setVO); } =20 ________________________________ From: xdo...@li... [mailto:xdo...@li...] On Behalf Of Rupp, Heiko Sent: Monday, October 18, 2004 1:10 PM To: xdo...@li... Subject: Re: [Xdoclet-user] Collection class not imported - VO's won't compile =20 As far as I recall are all Collection classes fully qualified. =20 There was report some time ago about this behaviour, but I think it is solved. =20 Hm. Can you show your input? =20 ________________________________ Von: xdo...@li... im Auftrag von Gemar, Edward Gesendet: Mo 18.10.2004 18:24 An: xdo...@li... Betreff: [Xdoclet-user] Collection class not imported - VO's won't compile Hi all, I've just upgraded to 1.2.2rc1 from 1.2b2 (for hibernate support) and now my EJB value objects won't compile because the Collection class isn't imported. This issue was brought up in April, but I haven't seen a JIRA against it and it's obviously a problem in latest release candidate. This is a major issue for us that breaks the build. Any ideas or workarounds? Thanks, Edward From: Lars Rohleder <l@ta...> Re: AW: Bug in xDoclet 1.2 final? =20 2004-04-16 00:29 Well, in version 1.2 (final) java.util.Collection doesn"t get imported nor is this class fully qualified in my value objects. And on JIRA I can"t find the bug (today JIRA seems to work). Lars On Thu, 2004-04-15 at 22:19, Rupp, Heiko wrote: > There is an item in Jira open wrt. this. > The current CVS version fully qualifies the collections as > java.util.Collection and does > not need the import. > I can"t really comment on 1.2 though. >=20 > Heiko > > ______________________________________________________________________ > Von: xdoclet-user-admin@li... im Auftrag von Lars > Rohleder > Gesendet: Do 15.04.2004 21:19 > An: xdoclet-user@li... > Betreff: [Xdoclet-user] Bug in xDoclet 1.2 final? > > > > Hi folks, > > I couldn"t find anything on the web or on this mailing list relating > this topic so I hope this hasn"t been asked earlier. > > After updating from xdoclet1.2b3 to xdoclet1.2 our project can"t be > compiled any more. It seems that the abstract value objects generated > from our entity beans are missing the import statement for > java.util.*. > Since we"re using collections I get a lot of error messages from ant. > > Using beta3 still works, 1.2.0 doesn"t. > I don"t think the taskdef or path definitions in our build.xml are > wrong. I didn"t change anything and upgrading to version 1.2.0 was > done > through changing the symbolic link to xdoclet to the new directory. > (And > of course I use this link in ant too.) > > Any suggestions? > > Lars > > > By the way: Where can I post bugs? Neither bug tracker on > SourceForge.net (closed) nor JIRA (error 404) will work. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > = administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck > _______________________________________________ > xdoclet-user mailing list > xdoclet-user@li... > https://lists.sourceforge.net/lists/listinfo/xdoclet-user > > > ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ xdoclet-user mailing list xdo...@li... https://lists.sourceforge.net/lists/listinfo/xdoclet-user |
From: Rupp, H. <Hei...@ce...> - 2004-10-18 20:07:50
|
Hi, =20 Now, I remember that entry :-) =20 The spec says in 10.3.1: The accessor methods for container-managed relationship fields for = one-to-many or many-to-many relationships must utilize one of the = following Collection interfaces: java.util.Collection or = java.util.Set[14]. The Collection interfaces used in relationships are = specified in the deployment descriptor. The implementation of the = collectionclasses used for the container-managed relationship fields is = supplied by the container. As you also have to give the parameters to finders as fully qualified = class names, I see the same applying to the result of a finder as well. = And VOs are (converted) returned objects from finders().=20 Interestingly the following comment to valueobjects.xdt is for 1.2b1 - everything is full qualified now, importedList removed from xdt files = and marked deprecated - removed system.out from catormapping handler ** make sure any type you generate is a full qualified class ** =20 ________________________________ Von: xdo...@li... im Auftrag von Gemar, = Edward Gesendet: Mo 18.10.2004 21:45 An: xdo...@li... Betreff: RE: [Xdoclet-user] Collection class not imported - VO's won't = compile Here is the input. Again, this works fine with xdoclet 1.2b2, but under = 1.2.2rc1 the value object won't compile due to a missing import for = Collection. Needless to say, the Collection class is *not* fully = qualified in the VO generated for this class by 1.2.2r1. We would very = much like to use the latest version of xdoclet for hibernate support = purposes, but this issue currently has us dead in the water since our = VOs will no longer compile. The only thing I saw regarding this was = this entry in the changelog. Does this mean that the Collection class = must be fully qualified in my bean now? This would be unfortunate as it = would break xdoclet 1.2+ backwards compatibility with previous versions. 2004-04-21 09:23:14 Heiko Rupp modules/ejb/src/META-INF/xtags.xml = <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xdoclet/xdoclet/modules/e= jb/src/META-INF/xtags.xml> v 1.43 = <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xdoclet/xdoclet/modules/e= jb/src/META-INF/xtags.xml?rev=3D1.43&content-type=3Dtext/vnd.viewcvs-mark= up> =20 Update documentation of @ejb.value-object wrt. type of possible = Collection types. Especially that those need to be fully qualified. = After a suggestion from Lars Rohleder [l.rohleder at tallence.de] Any insight is greatly appreciated. Thanks. =20 Edward =20 =20 Input: =20 package com.foo.management.alerts; =20 import com.foo.utils.logging.Logger; import javax.ejb.*; import java.util.*; =20 /** * Describes a set of levels that can be alerted on. Basically acts as * a container of {@link AlertLevelLocal} that can be chosen from the * interface when creating an alert rule. * * @version 1.0 05/10/2004 * * @zpm:genall * * @ejb.bean name=3D"AlertLevelSet" * local-jndi-name=3D"zpm_management_ejb_AlertLevelSet" * type=3D"CMP" * cmp-version=3D"2.x" * view-type=3D"local" * primkey-field=3D"iD" * * @ejb.persistence table-name=3D"rep_meta_alertLevelSet" * @jboss.container-configuration name=3D"ZPM Cached CMP EntityBean" * @jboss.persistence create-table=3D"false" remove-table=3D"false" * * @ejb.finder * signature=3D"java.util.Collection findAll()" * query=3D"SELECT OBJECT(r) FROM AlertLevelSet AS r" * * @ejb.transaction type=3D"Required" * @ejb.value-object name=3D"AlertLevelSet" match=3D"*" * @ejb.util generate=3D"physical" */ abstract public class AlertLevelSetBean implements EntityBean { private static final String CLASS_NAME =3D = AlertLevelSetBean.class.getName(); private static final Logger logger =3D = Logger.getLogger(CLASS_NAME); =20 /** * @ejb.persistence column-name=3D"setID" * @ejb.pk-field */ abstract public Integer getID(); abstract public void setID(Integer id); =20 /** * @return String display name of the level * * @ejb.persistence column-name=3D"displayName" * @ejb.interface-method */ abstract public String getDisplayName(); /** @ejb.interface-method */ abstract public void setDisplayName(String name); =20 /** * @return int sort order for display purposes * * @ejb.persistence column-name=3D"sortOrder" * @ejb.interface-method */ abstract public int getSortOrder(); /** @ejb.interface-method */ abstract public void setSortOrder(int order); =20 /** * @ejb.relation name=3D"AlertLevelSet-AlertLevel" * role-name=3D"AlertLevelSet-hasN-AlertLevels" * = target-role-name=3D"AlertLevel-BelongsToMany-AlertLevelSets" * target-ejb=3D"AlertLevel" * target-cascade-delete=3D"no" * target-multiple=3D"yes" * * @ejb.value-object = compose=3D"com.foo.management.alerts.AlertLevelVO" * compose-name=3D"Level" * = members=3D"com.foo.management.alerts.AlertLevelLocal" * members-name=3D"AlertLevelVO" * relation=3D"external" * type=3D"Collection" * * @jboss.relation related-pk-field=3D"iD" * fk-column=3D"levelID" * @jboss.target-relation related-pk-field=3D"iD" * fk-column=3D"setID" * @jboss.relation-mapping style=3D"relation-table" * @jboss.relation-table = table-name=3D"rep_meta_alertLevelSetToLevel" * create-table=3D"false" * remove-table=3D"false" * row-locking=3D"false" * @ejb.interface-method */ abstract public Collection getLevels(); /** @ejb.interface-method */ abstract public void setLevels(Collection levels); =20 =20 =20 /** * @ejb.create-method view-type=3D"local" */ public Integer ejbCreate(AlertLevelSetVO set) throws CreateException { setID(set.getID()); setDisplayName(set.getDisplayName()); setSortOrder(set.getSortOrder()); return null; } =20 /** * trying post create for setting the vo since we have relations... */ public void ejbPostCreate(AlertLevelSetVO set) throws = CreateException { setAlertLevelSetVO(set); } =20 /** @ejb.interface-method */ public abstract AlertLevelSetVO getAlertLevelSetVO(); =20 /** @ejb.interface-method */ public abstract void setAlertLevelSetVO(AlertLevelSetVO setVO); } =20 ________________________________ From: xdo...@li... = [mailto:xdo...@li...] On Behalf Of Rupp, = Heiko Sent: Monday, October 18, 2004 1:10 PM To: xdo...@li... Subject: Re: [Xdoclet-user] Collection class not imported - VO's won't = compile =20 As far as I recall are all Collection classes fully qualified. =20 There was report some time ago about this behaviour, but I think it is = solved. =20 Hm. Can you show your input? =20 ________________________________ Von: xdo...@li... im Auftrag von Gemar, = Edward Gesendet: Mo 18.10.2004 18:24 An: xdo...@li... Betreff: [Xdoclet-user] Collection class not imported - VO's won't = compile Hi all, I've just upgraded to 1.2.2rc1 from 1.2b2 (for hibernate = support) and now my EJB value objects won't compile because the = Collection class isn't imported. This issue was brought up in April, = but I haven't seen a JIRA against it and it's obviously a problem in = latest release candidate. This is a major issue for us that breaks the = build. Any ideas or workarounds? Thanks, Edward From: Lars Rohleder <l@ta...> Re: AW: Bug in xDoclet 1.2 final? =20 2004-04-16 00:29 Well, in version 1.2 (final) java.util.Collection doesn"t get imported nor is this class fully qualified in my value objects. And on JIRA I can"t find the bug (today JIRA seems to work). Lars On Thu, 2004-04-15 at 22:19, Rupp, Heiko wrote: > There is an item in Jira open wrt. this. > The current CVS version fully qualifies the collections as > java.util.Collection and does > not need the import. > I can"t really comment on 1.2 though. >=20 > Heiko > > = ______________________________________________________________________ > Von: xdoclet-user-admin@li... im Auftrag von Lars > Rohleder > Gesendet: Do 15.04.2004 21:19 > An: xdoclet-user@li... > Betreff: [Xdoclet-user] Bug in xDoclet 1.2 final? > > > > Hi folks, > > I couldn"t find anything on the web or on this mailing list relating > this topic so I hope this hasn"t been asked earlier. > > After updating from xdoclet1.2b3 to xdoclet1.2 our project can"t be > compiled any more. It seems that the abstract value objects generated > from our entity beans are missing the import statement for > java.util.*. > Since we"re using collections I get a lot of error messages from ant. > > Using beta3 still works, 1.2.0 doesn"t. > I don"t think the taskdef or path definitions in our build.xml are > wrong. I didn"t change anything and upgrading to version 1.2.0 was > done > through changing the symbolic link to xdoclet to the new directory. > (And > of course I use this link in ant too.) > > Any suggestions? > > Lars > > > By the way: Where can I post bugs? Neither bug tracker on > SourceForge.net (closed) nor JIRA (error 404) will work. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > = administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck > _______________________________________________ > xdoclet-user mailing list > xdoclet-user@li... > https://lists.sourceforge.net/lists/listinfo/xdoclet-user > > > ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give = us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out = more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ xdoclet-user mailing list xdo...@li... https://lists.sourceforge.net/lists/listinfo/xdoclet-user |