db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Minutes: JDO TCK Conference Call Friday, Nov 10, 9 am PST
Date Fri, 10 Nov 2006 19:26:14 GMT
Attendees: Michelle Caisse, Matthew Adams, Michael Bouschen, Craig  


1. Logistics for JDO maintenance release. Michael has proposed  
splitting the api20 and tck20 projects into two: one for 1.5 and the  
other for legacy (1.3). This will be the plan going forward unless  
objections are raised on the jdo-dev alias. We should probably do the  
split after most of the common work has been done. Craig has already  
renamed the JIRA categories to correspond to the new project names.

2.  Suggestion for new PMF setting javax.jdo.ClassLoader

 From Erik: When a JDBC driver is not loaded by the classloader ruled  
by JDO, there is no standard trick to make it work besides  
implementing the object factory (DriverManager is not designed for  
complex classpath). In JPOX, we have implemented a PMF setting where  
users can specify a ClassLoader for general use (it is the last one  
in search order). Do you think we could make this in the standard?

javax.jdo.ClassLoader which takes a java.lang.ClassLoader as value.

We assume that the intended use is for applications that specify the  
property javax.jdo.javax.jdo.option.ConnectionDriverName and  
class.forName on this property value results in class not found. So  
the jdbc driver is never registered with DriverManager.

Questions: Why doesn't the ContextClassLoader work? Is the intended  
usage in a managed environment? This method would need to be  
protected via a security permission, e.g. a JDOPermission 
("configurePersistenceManagerFactory") or a standard permission.

3. JDOHelper.getVersion(Object): Behaviour of jdo versioning. It  
seems that this is an underspecified part of the specification, as  
Marco points out.

Questions: For unmodified objects, should this always return an equal  
instance? For modified objects, should getVersion force a flush? If a  
flush has already happened, should a new Version always return a not- 
equal instance (compared to the Version at the beginning of the  
transaction)? If executed outside a transaction, is there any  
required behavior?

Action Items from weeks past:
[Oct 27 2006]  AI: Matthew add comment to JDO-403 regarding split  
between JDO and ORM annotations..

[Sep 1 2006] AI Craig  check into default handling to accommodate  
different defaults for annotations (?) based  on context. In progress.

[Aug 11 2006] AI Craig propose some semantics for behavior if user  
tries to add to a list where the ordering element is incorrect.

[Jul 14 2006] AI: Erik document 220 annotations that don't have a   
corresponding JDO concept.

[Jun 23 2006]  AI  Martin look at what Hibernate and TopLink support  
for Enum types. In progress.

[Apr 14 2006] AI Craig: update the roadmap for JDO. In progress.

[Nov 4 2005] AI Martin: Update Martin's wiki with discusion of JDK  
1.5 issues. In progress

[Sep 2 2005] AI: To recruit members, update the web site. Articles on  
TheServerSide directing attention to the site. T-shirts, logo. AI:   
Craig write a ServerSide article.

-- Michelle

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

View raw message