David,
Thank you for the detailed reply. Yes, Account to Campaign should be CMR. I need to fix that. And the code fragment * @ejb.persistence * column-campaign="campaign" is definitely a typo. My fault for doing a mindless global search and replace. Should be column-name="campaign" of course. But all this is besides the point. I think you're right. There is no way to do what I want, at least not if I want the container to manage all persistence of the field in question. The root of the problem is, as you said, the inability to override the getter in the bean class: Campaign getCampaign() CampaignLocal getCampaign() And to have a container persisted field, it's gotta be in the bean class in addition to the remote/local interface. So even if I forgot about xdoclet and wrote everything by hand there's no getting around this. My problem is more theoretical than anything. I just thought it would be cool to write each bean so that a client running within the same JVM/container and a client running remotely could both perform the same operations on the bean. It's not really necessary for my project. And your advice on VO's and session facades is well taken. I'm still at the point where I'm learning xdoclet and trying to hammer together the base entity bean classes. Thanks again, Mark ----- Original Message ----- From: "Harkness, David" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, August 03, 2003 11:05 PM Subject: RE: [Xdoclet-user] Remote and Local getter/setter > Hi Mark, > > Let me begin with a couple questions. Isn't your Account.campaign field actually a CMRelationship -- not a CMP field? Campaign is a full bean, and it's related to the Account bean by some foreign key in your database (most likely account.campaign_id -> campaign.id), correct? What then, is this: > > * @ejb.persistence > * column-campaign="campaign" > > "Column-campaign"?? Is this a typo/search-n-replace-accident? I'll assume so, otherwise I have no idea where to begin helping. :) > > That being said, I don't believe there is any way to do what you want. In fact, don't relationships have to use local interfaces? I've never tried it using remote interfaces, so I honestly don't know. I'd bet some money though that they must. Even if they do not, you'll need to create two different methods as you cannot overload the return type: > > Campaign getCampaign() > CampaignLocal getCampaign() > > This would be illegal. The interfaces would be okay as they are separate, but the bean itself couldn't define both methods. And if you created two versions of the methods, uniquely named, you'd end up defining two relationships entirely. > > In any case, I would recommend you at least incorporate value objects into your design. EJBDoclet will generate the code for you, and you'll end up using getCampaignVO() just like you would use getCampaign(). As well, value objects have support for relationships. This would make dealing with your EJB layer easier. > > Furthermore, I would also recommend using a session fa�ade layer in front of your entity beans. This way clients don't have to implement the persistence code, and you'll minimize your network traffic as the fa�ade would have higher-level methods like createAccount(accountVO) rather than the client calling AccountHome.ejbCreate and multiple setAttribute() methods, each of which involve a network round trip or at least serialization when in the same container. > > I just went one step further and created a business interface for the fa�ades, and remote and local delegates. The interface is basically the local interface (no RemoteExceptions), and each delegate is really a proxy for the remote or local stub. The remote version catches all RemoteExceptions, logs them, and throws an application-specific one (ServiceException in my case). The local interface is a complete pass-through proxy. > > The advantage to this is that I can give either the local or remote delegate to the client code *at runtime* without any client changes. Anyway, it's not overly exciting, but it also isn't that much extra work (mostly cut-n-paste). [Hmmm, new EJBDoclet task] > > This may not be exactly what you were hoping to hear, and maybe you'll hear from someone who has actually done what you want. However, even if it *can* be done, I'd recommend implementing the first two architectural changes above (value objects and session fa�ades). Good luck! > > David Harkness > Sony Pictures Digital Networks > (310) 482-4756 > > -----Original Message----- > From: Mark Markarian [mailto:[EMAIL PROTECTED] > Sent: Sunday, August 03, 2003 10:20 PM > To: [EMAIL PROTECTED] > Subject: [Xdoclet-user] Remote and Local getter/setter > > > I am writing beans that I would like to use from within the EJB container and from a remote client. I need both Local and Remote interfaces for my beans. I am trying to use xdoclet to generate both Local and Remote interface classes for my beans and am having a problem with getter/setter methods for properties that are other beans. > > For example, I have a base class called CampaignBean containing the xdoclet tags. Xdoclet will generate classes for CampaignBean, Campaign, CampaignHome, CampaignLocal and CampaignLocalHome. I can access methods in CampaignLocal and CampaignLocalHome from servlets running within the same JVM as the bean container (I'm using xdoclet xdoclet-1.2b.3 and Orion 2.0.2 on Windows XP). I can also access methods in Campaign and CampaignHome from a plain old runnable Java class that I execute from the command line. This all works as expected. > > However, I have another bean called Account that has a CMP field that is a Campaign bean. I would like to have my getter method (getCampaign) to return a CampaignLocal in AccountLocal and to return a Campaign object in Account. And I would like to have my setter method (setCampaign) accept a CampaignLocal in AccountLocal and to accept a Campaign object in Account. In other words, I want to end up with the following methods: > > In AccountLocal: > public CampaignLocal getCampaign() ; > public void setCampaign(CampaignLocal campaign) ; > > In Account: > public Campaign getCampaign() ; > public void setCampaign(Campaign campaign) ; > > The xdoclet tags I am using in AccountBean are: > /** > * @ejb.persistence > * column-campaign="campaign" > * @ejb.interface-method > * view-type="both" > **/ > public abstract CampaignLocal getCampaign(); > /** > * @ejb.interface-method > * view-type="both" > **/ > public abstract void setCampaign(CampaignLocal campaign); > > What I end up with in both AccountLocal and Account is: > public CampaignLocal getCampaign() ; > public void setCampaign(CampaignLocal campaign) ; > > > What I'm getting at is I would like my CMP fields that happen to be other beans to show up in both the local and remote interfaces just like all the other fields (like Strings, ints, etc.). Am I asking the impossible? Is this a general EJB 2.0 issue that has nothing to do with xdoclet? > > Thanks, > > Mark > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > xdoclet-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-user > ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
