|
Hi,
Now, I remember that entry :-)
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(). 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 **
Von: [EMAIL PROTECTED] im Auftrag von Gemar, Edward Gesendet: Mo 18.10.2004 21:45 An: [EMAIL PROTECTED] 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.
Any insight is greatly appreciated. Thanks.
Edward
Input:
package com.foo.management.alerts;
import com.foo.utils.logging.Logger; import javax.ejb.*; import java.util.*;
/** * Describes a set of levels that can be alerted on. Basically acts as * a container of [EMAIL PROTECTED] AlertLevelLocal} that can be chosen from the * interface when creating an alert rule. * * @version 1.0 05/10/2004 * * @zpm:genall * * @ejb.bean name="AlertLevelSet" * local-jndi-name="zpm_management_ejb_AlertLevelSet" * type="CMP" * cmp-version="2.x" * view-type="local" * primkey-field="iD" * * @ejb.persistence table-name="rep_meta_alertLevelSet" * @jboss.container-configuration name="ZPM Cached CMP EntityBean" * @jboss.persistence create-table="false" remove-table="false" * * @ejb.finder * signature="java.util.Collection findAll()" * query="SELECT OBJECT(r) FROM AlertLevelSet AS r" * * @ejb.transaction type="Required" * @ejb.value-object name="AlertLevelSet" match="*" * @ejb.util generate="physical" */ abstract public class AlertLevelSetBean implements EntityBean { private static final String CLASS_NAME = AlertLevelSetBean.class.getName(); private static final Logger logger = Logger.getLogger(CLASS_NAME);
/** * @ejb.persistence column-name="setID" * @ejb.pk-field */ abstract public Integer getID(); abstract public void setID(Integer id);
/** * @return String display name of the level * * @ejb.persistence column-name="displayName" * @ejb.interface-method */ abstract public String getDisplayName(); /** @ejb.interface-method */ abstract public void setDisplayName(String name);
/** * @return int sort order for display purposes * * @ejb.persistence column-name="sortOrder" * @ejb.interface-method */ abstract public int getSortOrder(); /** @ejb.interface-method */ abstract public void setSortOrder(int order);
/** * @ejb.relation name="AlertLevelSet-AlertLevel" * role-name="AlertLevelSet-hasN-AlertLevels" * target-role-name="AlertLevel-BelongsToMany-AlertLevelSets" * target-ejb="AlertLevel" * target-cascade-delete="no" * target-multiple="yes" * * @ejb.value-object compose="com.foo.management.alerts.AlertLevelVO" * compose-name="Level" * members="com.foo.management.alerts.AlertLevelLocal" * members-name="AlertLevelVO" * relation="external" * type="Collection" * * @jboss.relation related-pk-field="iD" * fk-column="levelID" * @jboss.target-relation related-pk-field="iD" * fk-column="setID" * @jboss.relation-mapping style="relation-table" * @jboss.relation-table table-name="rep_meta_alertLevelSetToLevel" * create-table="false" * remove-table="false" * row-locking="false" * @ejb.interface-method */ abstract public Collection getLevels(); /** @ejb.interface-method */ abstract public void setLevels(Collection levels);
/** * @ejb.create-method view-type="local" */ public Integer ejbCreate(AlertLevelSetVO set) throws CreateException { setID(set.getID()); setDisplayName(set.getDisplayName()); setSortOrder(set.getSortOrder()); return null; }
/** * trying post create for setting the vo since we have relations... */ public void ejbPostCreate(AlertLevelSetVO set) throws CreateException { setAlertLevelSetVO(set); }
/** @ejb.interface-method */ public abstract AlertLevelSetVO getAlertLevelSetVO();
/** @ejb.interface-method */ public abstract void setAlertLevelSetVO(AlertLevelSetVO setVO); }
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rupp, Heiko
As far as I recall are all Collection classes fully qualified.
There was report some time ago about this behaviour, but I think it is solved.
Hm. Can you show your input?
Von:
[EMAIL PROTECTED] im Auftrag von Gemar,
Edward Hi
all, |
Title: [Xdoclet-user] Collection class not imported - VO's won't compile
- [Xdoclet-user] Collection class not imported - VO's won't co... Gemar, Edward
- Re: [Xdoclet-user] Collection class not imported - VO's... Rupp, Heiko
- RE: [Xdoclet-user] Collection class not imported - VO's... Gemar, Edward
- Rupp, Heiko
