James, I saw something similar to this posted on the JBoss forums just a couple days ago [1]. It suggests instead (for Oracle users) to use "DEFERRABLE INITIALLY DEFERRED" when you define your column. This allows you to manage the CMR in the ejbPostCreate(...) where it's supposed to be based on the spec. (I'm currently working with the DBA here to test that, so I'll let everyone know when I do find out).
However, I'm still concerned as to HOW this is going to work. According to the spec, and the examples provided on the xdoclet site, there should be an abstract method defined in your bean class to set the relationship. This method should take an instance of a Local bean reference. Now, if you look at the add(..Value) method I posted earlier, the call that is made to home.create(...) does not consider passing the Local reference!! So even if the Oracle change mentioned above works, then there's still the issue of how I actually set the relationship with a reference to a Local EJB. Have you, or anyone reading this, managed to use CMR fields and VO's? I find it hard to believe that no one else is doing this (as it seems if it worked to save a lot of time). If so, I would really appreciate a look at the code that you wrote, and the code that was generated by XDoclet. Specifically, I am interested in the ejbCreate, ejbPostCreate, both Value classes, and the add(), remove() and update() methods on the parent CMP class. Thanks! Troy [1] http://www.jboss.org/thread.jsp?forum=46&thread=33677 -----Original Message----- From: James House [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 3:55 PM To: [EMAIL PROTECTED] Subject: Re: [Xdoclet-user] Updating CMR field through VO? Hi Troy, I ran into this same issue. Containers actually create records for both entities and then follow up with a SQL "update" command that puts in the foreign keys that link the relationship. I believe this is because the primary keys may not be created until the first insert occurs (depending on the scheme your entities use for generating the PKs). Because of this, your foreign-key columns MUST allow null values. Are you sure that your tables aren't defined with "not null" constraints on those columns? james Poppe, Troy wrote: >I based my code off the sample provided here: > >http://www.xdoclet.org/valueobjects.html > >Perhaps this wasn't the correct code to follow (I trusted it was because it was >managed by the xdoclet group). > >I am using XDoclet 1.2b2. > >It seems to me that somewhere in the EJB side code, there needs to be a call that >sets the relationship in terms of Local EJB references. I can't find code that >does something like this in any of the templates for value-object code >generation. > >Please, any one, any ideas? I need to get this working. > >Troy > > > >-----Original Message----- >From: Vikram Naik [mailto:[EMAIL PROTECTED] >Sent: Thursday, June 05, 2003 10:36 AM >To: [EMAIL PROTECTED] >Subject: Re: [Xdoclet-user] Updating CMR field through VO? > > >Hello, > > Which XDoclet version you are using .. because the version which i >have(1.2 b) doesn't method level tag for ejb.valueobject !! > >Regards, >Vikram > > > >----- Original Message ----- >From: "Poppe, Troy" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Thursday, June 05, 2003 3:53 PM >Subject: [Xdoclet-user] Updating CMR field through VO? > > > > >>I have defined a bi-directional, one-to-many CMR in two EJBs >> >> >(PerformancePlan and > > >>AssignedPerformanceElement) as seen below. Each of these EJBs has an >> >> >associated > > >>ValueObject. The PerformancePlanValue contains a Collection of >>AssignedPerformanceElements, and there are a number of additional >> >> >Collections > > >>that represent the AssignedPerformanceElements that have been added, >> >> >updated, or > > >>removed. >> >>I have created my EJBs as having ONLY local interfaces, and thus I have >> >> >wrappered > > >>them with a Session bean that is responsible for managing the interactions >> >> >with > > >>the client (a Struts application in this case). One of the methods >> >> >available to > > >>the Struts application is seen below. It takes as a parameter, an >> >> >instance of a > > >>PerformancePlanValue (presumably with some changes that need to be >> >> >updated, and > > >>persisted). Of particular interest here is the adding, creating, or >> >> >removing of > > >>AssignedPerformanceElements. >> >>In my code that calls updatePerformancePlan(PerformancePlanValue ppv), I >> >> >place a > > >>new AssignedPerformanceElementValue object into the PerformancePlanValue >> >> >object > > >>by calling >> >> >> >addAssignedPerformanceElement(gov.doe.eia.pms.AssignedPerformanceElementValu >e > > >>added). >> >>Unfortunately, when I get into the >>add(gov.doe.eia.pms.AssignedPerformanceElementValue added) method in >>PerformancePlanCMP, there's a section of code (seen below) that is >> >> >dynamically > > >>generated. No where in this section of code is there a call to >>setPerformancePlan(PerformancePlanLocal preformancePlan). This seems like >> >> >a > > >>local place to add the reference to the parent object. >> >>When the EJB container attempts to persist the new >> >> >AssignedPerformanceElement > > >>into the database, there's an execpted error: >> >>javax.ejb.CreateException: Could not create entity:java.sql.SQLException: >>ORA-01400: cannot insert NULL into >>("HR"."ASSIGNEDPERFORMANCEELEMENT"."PERFORMANCEPLANID") >> >>Is it my responsiblity as the EJB developer to do something that I'm not >> >> >doing to > > >>ensure that my relationships are referenced properly when I use >> >> >ValueObjects? Am > > >>I using the ValueObjects wrong? Is there something missing from XDoclet's >>dynamically generated code? >> >>Thanks. >> >>Troy Poppe >> >> >>---- >> >>public class PerformancePlanBean >>{ >>... >>/** >>* @ejb.relation >>* name = >>"AssignedPerformanceElementsInAPerformancePlanRelation" >>* role-name = >>"AssignedPerformancePlanHasPerformanceElements" >>* cascade-delete = "no" >>* >>* @ejb.interface-method >>* view-type = "local" >>* >>* @ejb.value-object >>* compose="gov.doe.eia.pms.AssignedPerformanceElementValue" >>* compose-name="AssignedPerformanceElement" >>* members="gov.doe.eia.pms.AssignedPerformanceElementLocal" >>* member-name="AssignedPerformanceElement" >>* relation="external" >>* type="Collection" >>* >>* @return >>*/ >>public abstract Collection getAssignedPerformanceElements(); >> >>/** >>* >>* @ejb.interface-method >>* view-type = "local" >>* >>* @param performanceElements >>*/ >>public abstract void setAssignedPerformanceElements(Collection >>assignedPerformanceElements); >>... >>} >> >> >>public class AssignedPerformanceElementBean >>{ >>... >>/** >>* @ejb.relation >>* name = >>"AssignedPerformanceElementsInAPerformancePlanRelation" >>* role-name = >>"AssignedPerformanceElementInAPerformancePlan" >>* >>* @ejb.interface-method >>* view-type = "local" >>* >>* @jboss.relation >>* fk-column = "performancePlanID" >>* related-pk-field = "performancePlanID" >>* >>* @author TPO >>*/ >>public abstract PerformancePlanLocal getPerformancePlan(); >> >>/** >>* @ejb.interface-method >>* view-type = "local" >>* >>* @jboss.relation >>* fk-column = "performancePlanID" >>* related-pk-field = "performancePlanID" >>* >>* @author TPO >>*/ >>public abstract void setPerformancePlan(PerformancePlanLocal >>preformancePlan); >>... >>} >> >> >>public PerformancePlanValue updatePerformancePlan(PerformancePlanValue >>ppv) >>{ >>PerformancePlanLocalHome pplHome = null; >>PerformancePlanLocal ppl = null; >> >>try >>{ >>pplHome = PerformancePlanUtil.getLocalHome(); >>} >>catch ( NamingException ex) >>{ >>} >> >>if ( ppv.getPerformancePlanID() == null ) >>{ >>// new PerformancePlan >>// NOTE: should probably check if the user is in the >>right role >>// to be creating a performance plan. >>try >>{ >>ppl = pplHome.create(ppv); >>} >>catch ( CreateException ex ) >>{ >>} >>} >>else >>{ >>// existing PerformancePlan >>try >>{ >>ppl = >>pplHome.findByPrimaryKey(ppv.getPerformancePlanID()); >>ppl.setPerformancePlanValue(ppv); >>} >>catch ( FinderException ex ) >>{ >>} >>} >>return ppl.getPerformancePlanValue(); >>} >> >> >> public void add(gov.doe.eia.pms.AssignedPerformanceElementValue added) >> throws javax.ejb.CreateException >> { >> try >> { >> java.lang.Integer pk = added.getAssignedPerformanceElementID(); >> >>gov.doe.eia.pms.AssignedPerformanceElementLocalHome home = >>gov.doe.eia.pms.AssignedPerformanceElementUtil.getLocalHome(); >> >>gov.doe.eia.pms.AssignedPerformanceElementLocal relation = >>home.create(added); >>getAssignedPerformanceElements().add(relation); >> } >> catch (Exception e){ >>if (e instanceof javax.ejb.CreateException) >>throw (javax.ejb.CreateException)e; >>else >>throw new javax.ejb.EJBException(e); >> } >> } >> >> >> >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: Etnus, makers of TotalView, The best >>thread debugger on the planet. Designed with thread debugging features >>you've never dreamed of, try TotalView 6 free at www.etnus.com. >>_______________________________________________ >>xdoclet-user mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/xdoclet-user >> >> >> > > >------------------------------------------------------- >This SF.net email is sponsored by: Etnus, makers of TotalView, The best >thread debugger on the planet. Designed with thread debugging features >you've never dreamed of, try TotalView 6 free at www.etnus.com. >_______________________________________________ >xdoclet-user mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/xdoclet-user > > > >------------------------------------------------------- >This SF.net email is sponsored by: Etnus, makers of TotalView, The best >thread debugger on the planet. Designed with thread debugging features >you've never dreamed of, try TotalView 6 free at www.etnus.com. >_______________________________________________ >xdoclet-user mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/xdoclet-user > > ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
