Re: Getting involved with cmp/jpa

[Dain Sundstrom <da...@iq80.com>]

I'm back from vacation and a coding bender on JaxRPC (working on a  
cxf based impl for openejb :D)

+1 everything David mentioned

Also there are a couple of big performance problems that shouldn't be  
that hard to fix.  When we execute a query or return a CMR  
collection, we read the entire collection into memory and wrap  
anything that needs to proxied (like cmp impl classes).  I  
implemented it this way because it was the simplest to get things  
going, but it really hurts performance.  Instead the JPA collection  
should be wrapped and proxy decisions should be made as the user  
executes methods on the collection (a streaming approach).  If the  
user never calls any methods on the collection, the JPA  
implementation may not need to read anything from the database.

Ping me on IRC if you need any help or explanations of what is going  
on.  I'm excited to have someone else wanting to learn this code!

-dain

On Nov 26, 2007, at 1:11 PM, David Blevins wrote:

> On Nov 26, 2007, at 11:13 AM, Rick McGuire wrote:
>
>> Been doing a bit of project-hopping of late, and openejb's number  
>> has come up again.  I'm thinking I'd love to get more involved  
>> with the cmp/jpa components.  Are there any task in that area that  
>> would make a good jumping in point that could use an extra worker  
>> bee?
>
> There are a couple limitations that I know are opportunities for  
> improvement.
>
> Here's an overview of how things work more or less.
>
> At deploy time we subclass all your cmp bean classes and include  
> some OpenEJB specific information in static fields in the generated  
> class. The generated classes are then added to a jpa mapping file.   
> The bulk of the information in that mapping file comes from  
> translating the ejb-jar.xml and the vendor cmp xml (like openejb- 
> jar.xml) to the jpa mapping.xml.  We then create a jpa  
> persistence.xml for the new persistence unit which wires the  
> generated cmp beans up to a data source and JPA persistence  
> provider. Then all three (generated classes, mapping xml,  
> persistence.xml) are added to a jar we generate and that jar is add  
> to the EJB or EAR archive.
>
> At runtime the cmp container for the most part only needs to use  
> the JPA api to perform most of it's work.  There are just a few  
> places where the two APIs don't match and the cmp container has to  
> do extra work.
>
>
> Ok, the limitations and areas for improvement....
>
> The biggest limitation is that we can't support just any JPA  
> provider.  We have some code in our JpaCmpEngine class which has an  
> OpenJPA specific lifecycle listener in it.  As I understand it,  
> most JPA implementations have similar listener style interfaces  
> that would allow us to support them as well.  Would be fantastic  
> and likely not that hard to have support for Hibernate.
>
> Another limitation is that your own JPA persistence units and  
> mappings are quite separate from the ones that we create for the  
> CMP beans.  I don't think we have the ability to add the generated  
> JPA beans to any existing persistence units that may be in your app  
> already or logical sounding rules for doing so.  It would be nice  
> if that were an option.  Similarly, we don't have the ability for  
> you to essentially take over the jpa mapping of your cmp beans  
> should you want to tweak some or add other non-cmp jpa beans to  
> it.  We'd need some logical rules for doing so that would be user  
> friendly and of course the code do make it happen.
>
> Overall, the feature of us supporting CMP through JPA has so much  
> more value if we really allow people to blur the line between the  
> two such that your legacy cmp beans and newly developed jpa beans  
> can both use the same persistence provider and persistence units.   
> You'd be able to take an existing CMP app and say, "from today on  
> all additions to this app will be done with JPA" as you'd  
> essentially just be adding more JPA which is no big deal.  We're  
> close but not quite there.
>
> Aside from those more advance features, we don't have any  
> documentation on CMP over JPA for developers or users and we don't  
> have any examples either.  That's a pretty high priority as well.
>
> Dain, any other thoughts?
>
> -David
>