portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: JPA_BRANCH status
Date Wed, 25 Feb 2009 00:40:58 GMT

On Feb 24, 2009, at 10:16 AM, Randy Watler wrote:

> Jetspeed on JPA is struggling to its feet. I have not tested beyond  
> bringing up the default page, but getting this far cleanly is reason  
> enough to give you all an update!
> - First, there is now a JPA branch for j2-admin. This was required  
> because of minor, but required, API changes to J2 itself. Nothing  
> serious, but I opted to create a branch rather than sharing a patch  
> file.
> - I have not modified all the maven plugins to support the JPA  
> configuration. This was more than I wanted to bite off at the moment  
> and it is unclear whether we'll support two configurations, (OJB and  
> JPA), going forward. Instead, I have added all the necessary  
> configurations, but left them supporting OJB mode by default. Here  
> is the list of changes one needs to manually complete to switch a  
> deployed OBJ version to use JPA:
> webapps/jetspeed/META-INF/context.xml:
>   uncomment the JPA NonXA datasource resource and JTA transactions  
> tags.
> webapps/jetspeed/WEB-INF/web.xml:
>   uncomment the jetspeed-xa datasource reference tags.
> webapps/jetspeed/WEB-INF/spring-filter.properties:
>   comment out the 'default,obj' default property.
>   uncomment the 'default,jpa' default property.
> Start the portal normally, and you should be in the brave new JPA  
> world!
> - I have yet to include a required JAR file for real XA support.  
> Will be doing that in the next few days. In the interim, only the  
> "fake" non-xa configuration is active. For those that are curious,  
> the non-xa configuration is perfectly safe for our typical  
> configuration of single database on a single server. A real XA  
> datasource is needed to include multiple databases as part of a  
> portal transaction that includes external database operations.

IIUC this stuff is all administration of portal configuration and any  
transaction should be entirely separate from any user application  
transactions.  I'm having trouble imagining a scenario where you would  
consider having this configuration info on more than one database.    
Have  I misunderstood? On the other hand, if there is only one  
database then xa isn't really any slower than non-xa since you use  
single phase commit.

BTW maybe you explained this in a post I missed but I've been  
wondering how you settled on the tm you are using rather than e.g. the  
geronimo tm and connector framework together with the jencks spring  
integration.  Aside from pushing projects named after me :-) I'm  
hoping for easy geronimo integration.... and in general if you're  
running in an ee app server using the servers' tm would be advisable.   
Anyway maybe this is already taken care of by spring.... I'm no expert.

> Please let me know if you are interested in helping me test the JPA  
> configuration. I could use some help in areas outside the default  
> demo setup on tomcat/mysql, specifically LDAP, other containers, and  
> other databases.

I'd love to help with geronimo but doubt I'll have time soon....  this  
has been one of the things I've wanted to work on for years now.

david jencks

> Randy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message