-
1. Re: JBossCMP fine with commit-option A?
pazu Mar 14, 2002 1:34 PM (in response to pazu)Things are getting stranger. Just noticed that these newly-inserted items have NO PRIMAY KEY. Selecting from the database shows the generated ID's, but the items in the CMR collection have no ids.
Also, now it seems that commit option B also got the same prablem, so it's not a commit option issue... I think I'll take a look at (xdoclet) generated source to see if I can find the source of this problem. -
2. Re: JBossCMP fine with commit-option A?
dsundstrom Mar 14, 2002 2:06 PM (in response to pazu)Quick question while you track this down: Are you using a custom pk? If so did you correctly implement equals? If not just ignore.
-
3. Re: JBossCMP fine with commit-option A?
pazu Mar 14, 2002 2:37 PM (in response to pazu)Sorry, folks. That was a problem with xDoclet generated Value Objects (which I's somewhat responsible for). I've already submited a patch and it should be commited soon.
If you're having the same problem, checkout xDoclet from CVS. The problem will be solved there. If you don't wanna fiddle with CVS version, contact me and I'll provide the patch.
I feel dumb. A topic where all posts are mine. -
4. Re: JBossCMP fine with commit-option A?
pajama Mar 14, 2002 3:23 PM (in response to pazu)What was the problem with XDoclet?
Thanks,
Ricardo -
5. Re: JBossCMP fine with commit-option A?
hubs2121 Mar 14, 2002 3:49 PM (in response to pazu)Can you explain the xdoclet problem further? I am using XDoclet and value objects as well, and I have a problem where updates made to the database from an external application are not being being picked up by my beans. Could this be related? I have made sure the commit config for JBoss is NOT set to A, so I am not sure why this is happening.
Thanks,
Steve -
6. Re: JBossCMP fine with commit-option A?
pazu Mar 15, 2002 8:06 AM (in response to pazu)The problem with xDoclet VO's is that all ValueObjects are created the first time they're requested (or at bean create time, for eager instatiation VO's) and never recreated again for that bean. The further times the VO is requested an internal cached instance is returned.
hubs, the bad news is that my patch won't solve your problem, I think. What my patch does is to invalidate the internally cached VO when the VO setter is called.
The setter does a lot of database work, so I thought it's better to invalidate the internal instance and let it be recreated (from database data) the next time it's requested than to make sure all DB changes are reflected in the VO.
In your case, the database is being changed in the back of the application, so there is no way for the bean to know when to reload the value object. This is really a VO deficiency. I'll write something to solve this now. Wait some time for a patch... -
7. xDoclet patch
pazu Mar 15, 2002 9:14 AM (in response to pazu)Well, here is the patch. I added the "volatile" parameter to the @ejb:value-object tag. If you specify @ejb:value-object volatile="true" then the VO will not be internally cached. I think this solves your problem.
I'm submitting this patch to xdoclet now. It should be in CVS version as soon as Vincent gets some time to commit this.
By the way: this patch is against the current (2002/03/15 14:18 GMT) CVS version. -
8. Re: xDoclet patch
hubs2121 Mar 15, 2002 9:55 AM (in response to pazu)Thanks, pazu!
I will check it out and see if that does the trick.
The only problem is that I have highly customized my version of the valueobject source so that it would work properly for what I wanted.
I haven't looked at the most recent cvs...does it now work properly with CMP2.0? If I remember correctly, I ran into several problems with how variables were named for PKs and relations.
Thanks,
Steve -
9. Re: xDoclet patch
pazu Mar 15, 2002 12:56 PM (in response to pazu)I think it is working fine now. I've been putting a lot of work into value objects in the last few weeks. I'm using them in my own CMP2 project. Check it out :)
-
10. Re: xDoclet patch
hubs2121 Mar 17, 2002 7:54 PM (in response to pazu)pazu,
I still have the same problems with the latest version from cvs.
At least two problems that I have encountered are:
In ejbLoad() and getMyBeanValue(), improperly formatted method calls are made when trying to set the value for a cmr field. For example, here is the line that is generated -
PersonnelValue.setDepartmentValue( getDepartment().getcom.elequip.interfaces.DepartmentValue() );
As you can see, it should be just getDepartmentValue() and the fully qualified class name should be included.
Secondly, in the setMyBeanValue() method, the same variable names get defined more than once for "pk" and "relation" if the method has to set the values for more than one cmr field.
I think these are all easy to fix, and I had my own (very ugly) hack to fix them, but I'd like to see it properly done and commited if possible, in case others run into the same thing.
Thanks,
Steve -
11. Re: xDoclet patch
pazu Mar 19, 2002 6:42 AM (in response to pazu)Ah, you shouldn't use the full classname (com.elequip.interfaces.DepartmentValue) in the VO tag. Use just the short classname (DepartmentValue) and make sure it's imported.
The duplicate variable definition problem has been fixed in my latests patches. Wait for a few days as xDoclet is now going through a massive refactoring. There are many patches pending, mine included I think. If you're really brave you may want to check out the latest version then apply the above patch. -
12. Re: xDoclet patch
hubs2121 Mar 19, 2002 8:19 AM (in response to pazu)Great, I can wait until the patches are commited, that's no problem.
One other thing I think I ran into was the use of getHome() instead of getLocalHome() when finding the pk for a related bean.
For CMP2.0, this should be getLocalHome(). Am I right, or am I doing something wrong, again! :)
Thanks,
Steve