geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: CMP Field Mapping Required?
Date Fri, 01 Jul 2005 23:50:18 GMT
+1 on Matt's idea

Maybe we should have a stand-alone tool that can generated a default  
configuration for any given jar.  This code would also be a good  
starting point for migration tool to come later.


On Jul 1, 2005, at 4:10 PM, Matt Hogstrom wrote:

> +1
> That's how WebSphere operates on a "vanillia" ejb-jar.  Makes life  
> a lot easier.  It only get's tough when you have to do meet-in-the  
> middle mapping.  What would be even nicer would be to accept an ear  
> with no deployment information and generate plans with the defaults  
> like this. So, for instance, if I wanted to deploy xyz.ear with  
> myejb.jar a deployment plan for the ear would include the OpenEJB  
> DDs with default values populated.  Then even meet-in-the middle  
> mapping would be a piece of cake.
> - Matt
> ----- Original Message -----
> From: "Aaron Mulder" <>
> To: <>
> Sent: Friday, July 01, 2005 2:39 PM
> Subject: CMP Field Mapping Required?
>> It looks like our intention is that cmp-field-mappings are
>> required in openejb-jar.xml.  That is, a single schema sequence  
>> contains
>> the table name and one or more cmp-field-mappings, which kind of  
>> implies
>> that you can't leave out the cmp-field-mappings, though of course  
>> there's
>> no way for us to force you (via the schema) to include one for  
>> each CMP
>> field in ejb-jar.xml.  Also, we do currently throw a deployment  
>> error if
>> you forget a field.
>> But I wonder whether this is all necessary.  We could just default
>> the column name to the CMP field name, so you would only need to  
>> provide
>> the mapping if they were different.  Likewise, we could default  
>> the table
>> name to the ejb-name and make that optional too.
>> What does everyone think about allowing defaults like that?  I
>> think it would be handy for trivial demos/examples, and unlikely  
>> to be
>> used for real apps.  All else being equal, I'm happy to support easy
>> examples.  But I'm not sure if people feel like explicit  
>> deployment errors
>> would be better than using defaults if you try to map everything but
>> forget one.
>> Aaron

View raw message