JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData

[smarlow]

I'm trying to add a getPersistenceMetaData() to PersistenceUnitMetaData, so that code that has access to the PersistenceUnitMetaData can also get the PersistenceMetaData.  This will help resolve JBJPA-27.

Attached to JBJPA-27 is a JBJPA-27.patch (https://jira.jboss.org/jira/secure/attachment/12333993/JBJPA-27.patch) that is written for https://svn.jboss.org/repos/jbossas/projects/metadata/ejb/trunk.  The patch changes PersistenceMetaData.setPersistenceUnits(List persistenceUnits) but unit testing is showing an empty List is passed in.  This isn't a surprise but I am wondering if there is a way to handle linking the classes via some other XML binding magic?

[alesj]

What about if you simply populated PUMDs with PMD on get instead of set?

+      for( Iterator<PersistenceUnitMetaData> iter = persistenceUnits.iterator(); iter.hasNext(); )
+      {
+         PersistenceUnitMetaData pumd = iter.next();
+         pumd.setPersistenceMetaData(this);
+      }

This code can be reduced a lot -- JDK5 for loop. ;-)

[smarlow]

Ales, that definitely helps the unit test pass but we would depend on the PersistenceMetaData.getPersistenceUnits() being called before a call to PersistenceUnitMetaData.getPersistenceMetaData() is made.

Your solutin is better than changing the code that doesn't have access to the PersistenceMetaData at the moment.  Thanks for the idea.  I will see if we can live with this delicate contract.

[smarlow]

Is there any reason why CollectionPropertyHandler.handle(PropertyInfopropertyInfo, TypeInfo propertyType, Object parent, Object child, QName
qName) couldn't call the the getter after setting the field?  It appears that we call the getter before the set, but not after.

It is no good to wait until the application calls the getter (since the application may first call PUMD.getPMD() which would return null.

If the convention is to put initialization logic in the getter, perhaps XB should call the getter after setting the field.

[jaikiran]

Scott Marlow wrote:

Is there any reason why CollectionPropertyHandler.handle(PropertyInfopropertyInfo, TypeInfo propertyType, Object parent, Object child, QName
qName) couldn't call the the getter after setting the field?  It appears that we call the getter before the set, but not after.

...

If the convention is to put initialization logic in the getter, perhaps XB should call the getter after setting the field.

Scott,

I haven't looked into the details of this thread (yet), but looking at this part of getter/setter, I guess it's related to this? http://community.jboss.org/thread/149235

[aloubyansky]

Could you clarify it once again? The way I read it is "the convention to initialize a property value after it has been initialized with the setter".

[smarlow]

When the collection is set, I need to do some special initialization on each item in the collection.  It might look something like this:

public List<PersistenceUnitMetaData> getPersistenceUnits()
   {
      if(NOT INITIALIZED YET)
      {
         for( Iterator<PersistenceUnitMetaData> iter = persistenceUnits.iterator(); iter.hasNext(); )
         {
            PersistenceUnitMetaData pumd = iter.next();
            pumd.setPersistenceMetaData(this);
         }
      }
      return persistenceUnits;
   }

I started out with this logic in the setter but found that null is passed in.  When the getter is called from CollectionPropertyHandler (I'm not on XB trunk yet), the collection hasn't been set yet (as by design in CollectionPropertyHandler.

Others have said that I should place my initialization logic in the getter (by convention).  I'm not sure if that is a XB convention or a more general convention that other XML parsing/processing libraries also use.

1.  I need a strong contract/convention that I can depend on with regard to custom initialization after the collection has been set.  Whether that is a setter or getter contract (I assume getter is better since it shouldn't mutate the collection).  I am mutating the objects referenced by the collection which can be a delicate operation (will need to avoid mutating the hashkey).

2.  I don't know the existing conventions that we might already depend on.  I am not making a case to make changes to current conventions that could break other XB dependent code.

I hope that helps illustrate what I am trying to do.

[smarlow]

If the solution described on http://community.jboss.org/thread/149235, was implemented (to invoke the setter with the collection value).  That would cover my needs.

[aloubyansky]

Ok, but it's still not clear how calling the getter after the setter  will help since the setter in the handler will set an empty collection.

And the getter, btw, is called for each item.

The feature Jaikiran mentioned won't work with unordered sequences (it would work fine if the collection items in the XML appeared in a proper sequence but if they are mixed with other elements the final collection value will only contain the last sequence of items, which makes sense if you think about it). So, when unordered sequences are enabled (which is currently the default in the AS https://jira.jboss.org/jira/browse/JBAS-6744) this feature is turned off.

[smarlow]

If the setter is invoked with the actual collection (instead of the current null value), then I don't care about the getter being invoked.  As I would move my initialization logic to the setter (which is a better place for me to mutate the objects held by the collection which also belong to me.)

[aloubyansky]

Is it really null or an empty collection?

If it is null then could you post a stack trace and the xb version?

[wolfc]

If I read JAXB 2.2 5.5.2.2 correctly it's correct that the CollectionPropertyHandler first calls List<Type> getId() to see if a collection exists. (In fact it says a setter is not allowed.)

To solve the problem at hand, PersistenceMetaData should return a 'managed' list which keeps track of additions. Similar to EnterpriseBeansMetaData. With some helpers it could probably be the list itself.

[smarlow]

I'll debug when I can build again.  I updated my settings.xml to the new maven repo (http://community.jboss.org/wiki/MavenSettingsExample-Developers) and can no longer build (http://pastebin.com/ypmSVvDy).

[aloubyansky]

It appears we have currently only 1.21-brew in JBoss thirdparty releases.

[smarlow]

I like this idea, so the PersistenceMetaData.getPersistenceUnits() will be changed to return a collection of PersistenceUnits via a managed class approach that tracks additions (allowing the PersistenceUnit back reference to PersistenceMetaData to be set).