-
1. Re: JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData
alesj Apr 28, 2010 9:13 AM (in response to smarlow)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. ;-)
-
2. Re: JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData
smarlow Apr 29, 2010 9:58 AM (in response to alesj)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.
-
3. Re: JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData
smarlow Apr 30, 2010 11:06 AM (in response to alesj)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.
-
4. Re: JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData
jaikiran Apr 30, 2010 11:09 AM (in response to smarlow)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
-
5. Re: JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData
aloubyansky Apr 30, 2010 11:18 AM (in response to smarlow)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".
-
6. Re: JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData
smarlow Apr 30, 2010 11:39 AM (in response to aloubyansky)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.
-
7. Re: JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData
smarlow Apr 30, 2010 11:43 AM (in response to 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.
-
8. Re: JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData
aloubyansky Apr 30, 2010 12:02 PM (in response to smarlow)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.
-
9. Re: JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData
smarlow Apr 30, 2010 12:12 PM (in response to aloubyansky)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.)
-
10. Re: JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData
aloubyansky Apr 30, 2010 12:45 PM (in response to smarlow)Is it really null or an empty collection?
If it is null then could you post a stack trace and the xb version?
-
11. Re: JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData
wolfc May 3, 2010 9:06 AM (in response to smarlow)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.
-
12. Re: JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData
smarlow May 3, 2010 1:24 PM (in response to aloubyansky)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).
-
13. Re: JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData
aloubyansky May 3, 2010 1:44 PM (in response to smarlow)It appears we have currently only 1.21-brew in JBoss thirdparty releases.
-
14. Re: JBJPA-27 and setting PersistenceUnitMetaData reference to PersistenceMetaData
smarlow May 3, 2010 2:00 PM (in response to wolfc)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).