[flexcoders] Re: LCDS: Problem with destination inheritance
I am running into this same problem below with a fill command. (Error: but we could not find a destination in the list of sub-types). Any thoughts on a workaround for just a simple fill of an extended destination? I must admit my frustration with LCDS is growing especially considering the recent change of licensing for LCDS 3. I have not had any luck with Adobe's very expensive paid support so continuing to dump money into their licenses/support seem futile. I am wondering if now is the time to migrate to another solution. Has anyone had better luck with WebOrb, GraniteDS or Blaze in terms of ease-of-use and community support? I primarily need Hibernate integration and real-time data push. Thanks for the help and advice, Kevin --- In flexcoders@yahoogroups.com, gordon_greg m...@... wrote: Hi Jeff, Thanks for the usual quick response, the workaround is fine for the time being, looking forward to the update release. greg --- In flexcoders@yahoogroups.com, Jeff Vroom jvroom@ wrote: Hi Greg, Yeah, thanks for sending this as it did uncover an LC DS bug. It occurs with the combination of the deleteItem and the commit(item) or commit([item]) case. The code is trying to look up the DataService associated with the item in the argument... to do that we look in the cache for each item. We can't find it (since it has been deleted) and the code is improperly returning the last data service in the list. So when it works, it is because the list of data services is generated in some particularly lucky order. If you can commit everything - not just that item, that would be an easy workaround though most likely you are using that variant of commit for a reason. I'll contact you off-list to get you a patched fds.swc to try out the fix. For your reference, the bug number I filed is: https://bugs.adobe.com/jira/browse/LCDS-351 Jeff From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of gordon_greg Sent: Thursday, July 03, 2008 12:53 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] LCDS: Problem with destination inheritance Hello, I'm using the latest LCDS 2.6.RC1 with the HibernateAssembler and a non-trivial data model that relies upon destination inheritance in a few places. In general everything works great, but occasionally, when I remove an element from a collection using dataService.deleteItem, when I then call dataService.commit, I end up with an exception that indicates that the wrong destination is being invoked... For our purposes, let's just deal with 4 destinations: Folder ResourceFolder (extends folder) Meeting MeetingParticipant (is a many-to-one child of Meeting) Now, if I call: meetingParticipantDataService.deleteItem(meetingParticipant); meetingParticipantDataService.commit([meetingParticipant],true); I end up with the following exception: == begin exception Error: Destination: spring.folder received an instance of class: demo.model.meetings::MeetingParticipant but we could not find a destination in the list of sub-types: spring.resourceFolder which extends this destination. at mx.data::ConcreteDataService/http://www.adobe.com/2006/flex/mx/internal::getDestinationForInstance()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\ConcreteDataService.as:5309] at mx.data::ConcreteDataService/http://www.adobe.com/2006/flex/mx/internal::getItemDestination()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\ConcreteDataService.as:5290] at mx.data::ConcreteDataService/http://www.adobe.com/2006/flex/mx/internal::getItemMetadata()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\ConcreteDataService.as:5275] at mx.data::MessageBatch/addMessageIdsForItem()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\MessageBatch.as:591] at mx.data::MessageBatch/extractMessages()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\MessageBatch.as:456] at mx.data::DataStore/http://www.adobe.com/2006/flex/mx/internal::doCommit()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\DataStore.as:1807] at mx.data::DataStore/http://www.adobe.com/2006/flex/mx/internal::internalCommit()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\DataStore.as:818] at mx.data::ConcreteDataService/commit()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\ConcreteDataService.as:337] at mx.data.mxml::DataService/commit()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\mxml\DataService.as:433] at [my code here] == end exception Note that there is no relationship at all between
Re: [flexcoders] Re: LCDS: Problem with destination inheritance
Hi Kevin, On your specific bug, the bug below where this error occurred improperly was fixed before I left Adobe. It could be a simple problem in your configuration or code. When you use sub-types in Java with hibernate and LCDS, you need a corresponding type hierarchy of ActionScript classes. If Foo extends Bar in Java and both are hibernate model classes, you need a Foo.as which has its remoteClass alias set to Foo.java and similar for Bar. You might also check the XML downloaded from the server at the time this error occurs. It is in flex.messaging.config.ServerConfig.xml (a static property). If you dump that out you should see destinations which match up with the type hierarchy for your model. Jeff On Wed, Feb 24, 2010 at 7:26 AM, Jeff li...@kevinmerritt.com wrote: I am running into this same problem below with a fill command. (Error: but we could not find a destination in the list of sub-types). Any thoughts on a workaround for just a simple fill of an extended destination? I must admit my frustration with LCDS is growing especially considering the recent change of licensing for LCDS 3. I have not had any luck with Adobe's very expensive paid support so continuing to dump money into their licenses/support seem futile. I am wondering if now is the time to migrate to another solution. Has anyone had better luck with WebOrb, GraniteDS or Blaze in terms of ease-of-use and community support? I primarily need Hibernate integration and real-time data push. Thanks for the help and advice, Kevin --- In flexcoders@yahoogroups.com flexcoders%40yahoogroups.com, gordon_greg m...@... wrote: Hi Jeff, Thanks for the usual quick response, the workaround is fine for the time being, looking forward to the update release. greg --- In flexcoders@yahoogroups.com flexcoders%40yahoogroups.com, Jeff Vroom jvroom@ wrote: Hi Greg, Yeah, thanks for sending this as it did uncover an LC DS bug. It occurs with the combination of the deleteItem and the commit(item) or commit([item]) case. The code is trying to look up the DataService associated with the item in the argument... to do that we look in the cache for each item. We can't find it (since it has been deleted) and the code is improperly returning the last data service in the list. So when it works, it is because the list of data services is generated in some particularly lucky order. If you can commit everything - not just that item, that would be an easy workaround though most likely you are using that variant of commit for a reason. I'll contact you off-list to get you a patched fds.swc to try out the fix. For your reference, the bug number I filed is: https://bugs.adobe.com/jira/browse/LCDS-351 Jeff From: flexcoders@yahoogroups.com flexcoders%40yahoogroups.com[mailto: flexcoders@yahoogroups.com flexcoders%40yahoogroups.com] On Behalf Of gordon_greg Sent: Thursday, July 03, 2008 12:53 PM To: flexcoders@yahoogroups.com flexcoders%40yahoogroups.com Subject: [flexcoders] LCDS: Problem with destination inheritance Hello, I'm using the latest LCDS 2.6.RC1 with the HibernateAssembler and a non-trivial data model that relies upon destination inheritance in a few places. In general everything works great, but occasionally, when I remove an element from a collection using dataService.deleteItem, when I then call dataService.commit, I end up with an exception that indicates that the wrong destination is being invoked... For our purposes, let's just deal with 4 destinations: Folder ResourceFolder (extends folder) Meeting MeetingParticipant (is a many-to-one child of Meeting) Now, if I call: meetingParticipantDataService.deleteItem(meetingParticipant); meetingParticipantDataService.commit([meetingParticipant],true); I end up with the following exception: == begin exception Error: Destination: spring.folder received an instance of class: demo.model.meetings::MeetingParticipant but we could not find a destination in the list of sub-types: spring.resourceFolder which extends this destination. at mx.data::ConcreteDataService/ http://www.adobe.com/2006/flex/mx/internal::getDestinationForInstance ()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\ConcreteDataService.as:5309] at mx.data::ConcreteDataService/ http://www.adobe.com/2006/flex/mx/internal::getItemDestination ()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\ConcreteDataService.as:5290] at mx.data::ConcreteDataService/ http://www.adobe.com/2006/flex/mx/internal::getItemMetadata ()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\ConcreteDataService.as:5275] at
[flexcoders] Re: LCDS: Problem with destination inheritance
Hi Jeff, Thanks for the usual quick response, the workaround is fine for the time being, looking forward to the update release. greg --- In flexcoders@yahoogroups.com, Jeff Vroom [EMAIL PROTECTED] wrote: Hi Greg, Yeah, thanks for sending this as it did uncover an LC DS bug. It occurs with the combination of the deleteItem and the commit(item) or commit([item]) case. The code is trying to look up the DataService associated with the item in the argument... to do that we look in the cache for each item. We can't find it (since it has been deleted) and the code is improperly returning the last data service in the list. So when it works, it is because the list of data services is generated in some particularly lucky order. If you can commit everything - not just that item, that would be an easy workaround though most likely you are using that variant of commit for a reason. I'll contact you off-list to get you a patched fds.swc to try out the fix. For your reference, the bug number I filed is: https://bugs.adobe.com/jira/browse/LCDS-351 Jeff From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of gordon_greg Sent: Thursday, July 03, 2008 12:53 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] LCDS: Problem with destination inheritance Hello, I'm using the latest LCDS 2.6.RC1 with the HibernateAssembler and a non-trivial data model that relies upon destination inheritance in a few places. In general everything works great, but occasionally, when I remove an element from a collection using dataService.deleteItem, when I then call dataService.commit, I end up with an exception that indicates that the wrong destination is being invoked... For our purposes, let's just deal with 4 destinations: Folder ResourceFolder (extends folder) Meeting MeetingParticipant (is a many-to-one child of Meeting) Now, if I call: meetingParticipantDataService.deleteItem(meetingParticipant); meetingParticipantDataService.commit([meetingParticipant],true); I end up with the following exception: == begin exception Error: Destination: spring.folder received an instance of class: demo.model.meetings::MeetingParticipant but we could not find a destination in the list of sub-types: spring.resourceFolder which extends this destination. at mx.data::ConcreteDataService/http://www.adobe.com/2006/flex/mx/internal::getDestinationForInstance()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\ConcreteDataService.as:5309] at mx.data::ConcreteDataService/http://www.adobe.com/2006/flex/mx/internal::getItemDestination()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\ConcreteDataService.as:5290] at mx.data::ConcreteDataService/http://www.adobe.com/2006/flex/mx/internal::getItemMetadata()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\ConcreteDataService.as:5275] at mx.data::MessageBatch/addMessageIdsForItem()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\MessageBatch.as:591] at mx.data::MessageBatch/extractMessages()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\MessageBatch.as:456] at mx.data::DataStore/http://www.adobe.com/2006/flex/mx/internal::doCommit()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\DataStore.as:1807] at mx.data::DataStore/http://www.adobe.com/2006/flex/mx/internal::internalCommit()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\DataStore.as:818] at mx.data::ConcreteDataService/commit()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\ConcreteDataService.as:337] at mx.data.mxml::DataService/commit()[C:\depot\flex\branches\enterprise_corfu_rc\frameworks\projects\data\src\mx\data\mxml\DataService.as:433] at [my code here] == end exception Note that there is no relationship at all between MeetingParticipant and Folder - they are completely independent of each other. This feels like a bug to me, because it doesn't always happen, is not reliable reproduced, and once it does happen it keeps happening until I clean out my browser's cache. Somehow, something gets the DataService layer in an unstable state, possibly as a side effect of some exception being thrown somewhere in my application (although this isn't clear either), and once it is in that state, it doesn't recover. Is anyone else seeing this? Should I be reporting this as a bug? I'd be happy to provide more information as necessary. Thanks.
