[svn:fx-trunk] 8575: Some fixes to deeplinking

Revision: 8575
Author:   [email protected]
Date:     2009-07-14 22:35:58 -0700 (Tue, 14 Jul 2009)
Log Message:
Some fixes to deeplinking
QE Notes: None
Doc Notes: None
Bugs: SDK-14664, SDK-14289
Reviewer: Corey
tests: checkintests
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-14664
    http://bugs.adobe.com/jira/browse/SDK-14289
Modified Paths:
    flex/sdk/trunk/templates/swfobject/history/history.js
    flex/sdk/trunk/templates/swfobject/index.template.html

Similar Messages

[svn:fx-trunk] 11223: * Quick fix for some mxmlcunit failures.

Revision: 11223
Author:   [email protected]
Date:     2009-10-28 07:12:00 -0700 (Wed, 28 Oct 2009)
Log Message:
Quick fix for some mxmlcunit failures.
QE notes:
Doc notes:
Bugs: SDK-23865
Reviewer: Gaurav
Tests run: checkintests
Is noteworthy for integration: No
Code-level description of changes:
Added null destination check to completeTwoWayBindings().
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-23865
Modified Paths:
    flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/mxml/rep/MxmlDocument.java

[svn:bz-trunk] 18839: bug fix BLZ-575 Potential race condition in flex. management.runtime.messaging.endpoints.EndpointControl

Revision: 18839
Revision: 18839
Author:   [email protected]
Date:     2010-11-29 12:26:32 -0800 (Mon, 29 Nov 2010)
Log Message:
bug fix BLZ-575 Potential race condition in flex.management.runtime.messaging.endpoints.EndpointControl
Change a few counters to Atomic numbers
Probably solve some PMD bugs too (was complaining about new Integer() and new Long() API)
Ticket Links:
    http://bugs.adobe.com/jira/browse/BLZ-575
Modified Paths:
    blazeds/trunk/modules/core/src/flex/management/runtime/messaging/endpoints/EndpointContro l.java

[svn:fx-trunk] 7605: VideoPlayer fixes:

Revision: 7605
Author:   [email protected]
Date:     2009-06-07 12:40:59 -0700 (Sun, 07 Jun 2009)
Log Message:
VideoPlayer fixes:
-Going in to fullScreen mode, push the videoplayer on to the application directly as a child. Otherwise there?\226?\128?\153s no way to guarentee the right coordinates to use when setting the fullScreenRect as I noticed they may change later on.
- Fix up fullScreen mode to deal with not having access to topLevelRoot()
- Hide the popup when the ?\226?\128?\1563 second no user-interaction?\226?\128?\157 occurs in fullscreen mode.
- Remove playheadTime setter from VideoElement...it wasn?\226?\128?\153t supposed to be on there. They should use seek() instead. VideoPlayer is correct here.
- When switching skins, we keep track of the video element?\226?\128?\153s state (where it was in the playback and whether it was playing)
- In VideoElement, sometimes the underlying object would send out a STOP state change handler after calling play() due to its asynchronous nature. We call setPlaying() when someone calls play() or pause() or stop() so that the controls update to what the user is trying to do, but when a stop occurs because of end of video, we still need to setPlaying(false). Also, in this case, when we get a Play stateChange, we should call setPlaying(true).
- Make sure we call videoPlayer.stop() when swapping video element?\226?\128?\153s or when swapping the underlyign video player object
QE Notes: -
Doc Notes: -
Bugs:SDK-21508, SDK-21616, SDK-21255
Reviewer: Alex
tests: checkintest
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-21508
    http://bugs.adobe.com/jira/browse/SDK-21616
    http://bugs.adobe.com/jira/browse/SDK-21255
Modified Paths:
    flex/sdk/trunk/frameworks/projects/flex4/src/spark/components/VideoPlayer.as
    flex/sdk/trunk/frameworks/projects/flex4/src/spark/primitives/VideoElement.as

[svn:bz-trunk] 20650: Some MBean tests needed flex.management. jmx stuff in the allow classes list for the class deserialization validator so adding it in on BlazeDS trunk .

Revision: 20650
Revision: 20650
Author:   [email protected]
Date:     2011-03-07 12:20:03 -0800 (Mon, 07 Mar 2011)
Log Message:
Some MBean tests needed flex.management.jmx stuff in the allow classes list for the class deserialization validator so adding it in on BlazeDS trunk.
Modified Paths:
    blazeds/trunk/qa/apps/qa-regress/WEB-INF/flex/services-config.mods.validators.xml

Thank you very much!
I cant believe this little comment has been so helpful!
But yes it is:
I explain, despite my efforts to find, googled it, forums, faqs, etc...
no where it mentionned the manifest.fm file is... INSIDE the .jar!
Your comment "a zip" made me attempt to open it with winrar, and I found a manifest.fm file inside!
So far I was editing the one at the "source" of my project and rebuilding it with netbeans.
I am going to try that now.
Actually.... :( no its mentionning my main class!
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 10.0-b19 (Sun Microsystems Inc.)
Main-class: courseworkjava3d.Simple3D
Class-Path:
X-COMMENT: Main-Class will be added automatically by buildWell I have no problems uploading you the .jar, it is for a coursework it is not a private project or whatever:
http://www.uploading.com/files/CM2LKWYU/BetaCourseworkJava3d_Final.jar.html
Oh and I felt on your comment "dont ask us" as if I was suppose to know... i'm a beginner, I did not know that! And I tried to give you so many infos so you dont lose your time if you want to help, especially as after my own research I found many, many results for this "main class" and I tried a few solutions!
Edited by: CupofTea on Apr 13, 2008 3:28 AM

[svn:bz-trunk] 18926: bug fix BLZ-570 Double linked list with lot of objects result in BlazeDS Error deserializing error : StackOverflowError

Revision: 18926
Revision: 18926
Author:   [email protected]
Date:     2010-12-01 14:07:19 -0800 (Wed, 01 Dec 2010)
Log Message:
bug fix BLZ-570 Double linked list with lot of objects result in BlazeDS Error deserializing error : StackOverflowError
We put hard limit to the max object nest level to prevent StackOverFlowError. the default max object nest level is 1024 and it can be configured in the endpoint/serialziation section in service-config.xml.
This needs documentation.
Checkintests pass
Ticket Links:
    http://bugs.adobe.com/jira/browse/BLZ-570
Modified Paths:
    blazeds/trunk/modules/common/src/flex/messaging/errors.properties
    blazeds/trunk/modules/core/src/flex/messaging/endpoints/AbstractEndpoint.java
    blazeds/trunk/modules/core/src/flex/messaging/io/SerializationContext.java
    blazeds/trunk/modules/core/src/flex/messaging/io/amf/Amf0Input.java
    blazeds/trunk/modules/core/src/flex/messaging/io/amf/Amf3Input.java
    blazeds/trunk/modules/core/src/flex/messaging/io/amf/AmfIO.java

[svn:bz-trunk] 21394: bug fix for watson 2887837 Not getting duplicate session detected error when same flex client id is used from two different HTTP sessions in CRX .

Revision: 21394
Revision: 21394
Author:   [email protected]
Date:     2011-06-16 12:34:13 -0700 (Thu, 16 Jun 2011)
Log Message:
bug fix for watson 2887837 Not getting duplicate session detected error when same flex client id is used from two different HTTP sessions in CRX.
get the sessions id before we invalidate the duplicate session.
Checkintests pass
Modified Paths:
    blazeds/trunk/modules/core/src/flex/messaging/endpoints/BaseHTTPEndpoint.java

For our profect I think this issue was caused as follows:
Believing that remoting was full asynchronous we fired a 2 or 3 remote calls to the server at the same time ( within the same function ) - usually when the users goes to a new section of the app.
This seemed to trigger the duplicate http session error since according to http://blogs.adobe.com/lin/2011/05/duplication-session-error.html two remote calls arriving before a session is created will cause 2 sessions to be created.
Our current solution ( too early to say it works ) is to daisy chain the multiple calls together .
Also there seemed to be an issue where mobile apps that never quit ( thanks Apple! ) caused the error when activated after a few hours.
I guess the session expires on the server and the error above occurs on activation.
So the mobile apps now ping the server with a remote call when activated after sleeping for more than one hour.
All duplicate http errors are silently caught and reported.
Fingers crossed we won't get any more!

[svn:bz-trunk] 10631: Proper fix for BLZ-343 and LCDS-1153.

Revision: 10631
Author:   [email protected]
Date:     2009-09-28 05:23:42 -0700 (Mon, 28 Sep 2009)
Log Message:
Proper fix for BLZ-343 and LCDS-1153.
Refactored the common logic for AMF0 and AMF3 back into AbstractAmfInput. Resolving class aliases, creating and registering a property proxy and instantiating the appropriate class are now handled in the superclass. The resolved className and the proxy are 'returned' to the subclasses via a holder array created in the subclasses and sent as a parameter.
blazeDS checkintests pass
lcds-trunk checkintests pass with the new flex-messaging-core.jar
lcds-trunk alltests-dataservice pass with the new flex-messaging-core.jar
Ticket Links:
    http://bugs.adobe.com/jira/browse/BLZ-343
    http://bugs.adobe.com/jira/browse/LCDS-1153
Modified Paths:
    blazeds/trunk/modules/core/src/flex/messaging/io/amf/AbstractAmfInput.java
    blazeds/trunk/modules/core/src/flex/messaging/io/amf/Amf0Input.java
    blazeds/trunk/modules/core/src/flex/messaging/io/amf/Amf3Input.java

[svn:bz-trunk] 19323: Revert fix for BLZ-578 (checkin 19214).

Revision: 19323
Revision: 19323
Author:   [email protected]
Date:     2010-12-13 12:10:28 -0800 (Mon, 13 Dec 2010)
Log Message:
Revert fix for BLZ-578 (checkin 19214). The BlazeDS/LCDS Spring integration code had a dependency on the thread local stuff that was removed as part of this bug fix. Revert the fix so we can move forward with lockdown testing. We can add this change back in when we resolve the dependency issue (tracked by Watson 2774331) if that's the appropriate thing to do.
Ticket Links:
    http://bugs.adobe.com/jira/browse/BLZ-578
Modified Paths:
    blazeds/trunk/modules/core/src/flex/messaging/FlexContext.java
    blazeds/trunk/modules/core/src/flex/messaging/MessageBroker.java
    blazeds/trunk/modules/core/src/flex/messaging/MessageBrokerServlet.java
    blazeds/trunk/modules/core/src/flex/messaging/MessageException.java

[svn:bz-trunk] 21494: bug fix BLZ-581 Possible deadlock situation when sending message

Revision: 21494
Revision: 21494
Author:   [email protected]
Date:     2011-06-29 11:25:54 -0700 (Wed, 29 Jun 2011)
Log Message:
bug fix BLZ-581 Possible deadlock situation when sending message
change the scope of lock EndpointPushNotifier.pushNeeded to be minimal (retrieving the messages from the message buffer), that way, we can avoid the connection write failure to occupy the lock forever.
Checkintests pass
Ticket Links:
    http://bugs.adobe.com/jira/browse/BLZ-581
Modified Paths:
    blazeds/trunk/modules/core/src/flex/messaging/endpoints/BaseStreamingHTTPEndpoint.java

Adobe has donated BlazeDS to the Apache Flex community, and the source code is hosted on the Apache Flex website in a GIT repository.
http://flex.apache.org/dev-sourcecode.html

[svn:bz-trunk] 21209: bug fix BLZ-581 Possible deadlock situation when sending message

Revision: 21209
Revision: 21209
Author:   [email protected]
Date:     2011-05-04 18:26:18 -0700 (Wed, 04 May 2011)
Log Message:
bug fix BLZ-581 Possible deadlock situation when sending message
change the scope of lock EndpointPushNotifier.pushNeeded to be minimal (retrieving the messages from the message buffer), that way, we can avoid the connection write failure to occupy the lock forever.
Checkintests pass
Ticket Links:
    http://bugs.adobe.com/jira/browse/BLZ-581
Modified Paths:
    blazeds/trunk/modules/core/src/flex/messaging/endpoints/BaseStreamingHTTPEndpoint.java

Adobe has donated BlazeDS to the Apache Flex community, and the source code is hosted on the Apache Flex website in a GIT repository.
http://flex.apache.org/dev-sourcecode.html

[svn:fx-trunk] 10214: This fixes the problem that if two text components share the same textFlow there is an infinite loop involving updateDisplayList - damageHandler - invalidateDisplaylist - back to updateDisplayList.

Revision: 10214
Author:   [email protected]
Date:     2009-09-13 07:33:58 -0700 (Sun, 13 Sep 2009)
Log Message:
This fixes the problem that if two text components share the same textFlow there is an infinite loop involving updateDisplayList -> damageHandler -> invalidateDisplaylist -> back to updateDisplayList. The bug file was for TextArea which is RET but the same bug was in RichText as well.
This example with a renderer exposed it because the typicalItem that is composed to figure out sizes and the actual first item in the list share the same textFlow. It actually has nothing to do with useVirtualDisplay other than it was sharing a textFlow.
It turns out that the TextFlowFactory dispatches damage events every time the textFlow is composed. Unlike when the flowComposer is used, it always considers the flow damaged. It was exacerbated by each of the two components having a damage handler for the same textFlow.
The solution is to use the textFlow generation number. In the damageHandler if the generation is the last known generation number, assume no changes, and return immediately from the damage handler.
QE notes: There are 1 TextArea, 6 TextInput and 2 NumericStepper failuers, with or without my changes. The common link seems to be DispatchKeyEvent. Most were testing maxChar, displayAsPassword and restrict. I tested these and they seem to be working correctly.
Doc notes:
Bugs: SDK-23002
Reviewer: Gordon
Tests run: checkintests, TextArea, TextInput and NumericStepper
Is noteworthy for integration: no
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-23002
Modified Paths:
    flex/sdk/trunk/frameworks/projects/spark/src/spark/components/RichEditableText.as
    flex/sdk/trunk/frameworks/projects/spark/src/spark/components/RichText.as
    flex/sdk/trunk/frameworks/projects/spark/src/spark/components/supportClasses/RichEditable TextContainerManager.as

Revision: 10214
Author:   [email protected]
Date:     2009-09-13 07:33:58 -0700 (Sun, 13 Sep 2009)
Log Message:
This fixes the problem that if two text components share the same textFlow there is an infinite loop involving updateDisplayList -> damageHandler -> invalidateDisplaylist -> back to updateDisplayList. The bug file was for TextArea which is RET but the same bug was in RichText as well.
This example with a renderer exposed it because the typicalItem that is composed to figure out sizes and the actual first item in the list share the same textFlow. It actually has nothing to do with useVirtualDisplay other than it was sharing a textFlow.
It turns out that the TextFlowFactory dispatches damage events every time the textFlow is composed. Unlike when the flowComposer is used, it always considers the flow damaged. It was exacerbated by each of the two components having a damage handler for the same textFlow.
The solution is to use the textFlow generation number. In the damageHandler if the generation is the last known generation number, assume no changes, and return immediately from the damage handler.
QE notes: There are 1 TextArea, 6 TextInput and 2 NumericStepper failuers, with or without my changes. The common link seems to be DispatchKeyEvent. Most were testing maxChar, displayAsPassword and restrict. I tested these and they seem to be working correctly.
Doc notes:
Bugs: SDK-23002
Reviewer: Gordon
Tests run: checkintests, TextArea, TextInput and NumericStepper
Is noteworthy for integration: no
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-23002
Modified Paths:
    flex/sdk/trunk/frameworks/projects/spark/src/spark/components/RichEditableText.as
    flex/sdk/trunk/frameworks/projects/spark/src/spark/components/RichText.as
    flex/sdk/trunk/frameworks/projects/spark/src/spark/components/supportClasses/RichEditable TextContainerManager.as

[svn:bz-trunk] 19400: bug fix for watson 2774405 Authentication sync sample didn' t work in weblogic

Revision: 19400
Revision: 19400
Author:   [email protected]
Date:     2010-12-15 12:28:20 -0800 (Wed, 15 Dec 2010)
Log Message:
bug fix for watson 2774405 Authentication sync sample didn't work in weblogic
We should check whether we can cast the user principal to our impl first, also weblogic.security.Security.getCurrentSubject() is used in case it is not our impl
Modified Paths:
    blazeds/trunk/modules/opt/src/weblogic/flex/messaging/security/WeblogicLoginCommand.java

[svn:fx-trunk] 8057: Some errant renames in the project properties files.

Revision: 8057
Author:   [email protected]
Date:     2009-06-22 12:27:26 -0700 (Mon, 22 Jun 2009)
Log Message:
Some errant renames in the project properties files.
Modified Paths:
    flex/sdk/trunk/development/eclipse/flex/airframework/.actionScriptProperties
    flex/sdk/trunk/development/eclipse/flex/flash-integration/.project
    flex/sdk/trunk/development/eclipse/flex/sparkTest/.actionScriptProperties

Thats good news.

[svn:fx-trunk] 11642: Simple fix for non-integer translations by first multiplying to twips before casting to int .

Revision: 11642
Author:   [email protected]
Date:     2009-11-10 19:40:31 -0800 (Tue, 10 Nov 2009)
Log Message:
Simple fix for non-integer translations by first multiplying to twips before casting to int.
QE notes: Please test non-integer translations in FXG.
Doc notes: N/A
Bugs:
SDK-24110 - Drawing of compiled FXG items is off by half a pixel
Reviewer: Peter DeHaan
Tests run: Checkintests, Bug test case
Is noteworthy for integration: No
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-24110
Modified Paths:
    flex/sdk/trunk/modules/fxgutils/src/java/com/adobe/internal/fxg/types/FXGMatrix.java

i dont know why you are so mean i just asked which
wrongs i had wrong
anyway im done with thoseSo, the questions have 4 alternative answers. We tell you which questions you got wrong. This eleminates one of
the alternatives, leaving 3 choices. Usually in most mutlichoice questions 1 choice is obviously incorrect,
leaving 2 choices. One of those you have probably already discarded when you initially made your incorrect chocie
thus leaving 1 alternative. Congratulations you just 100% on your test. I don't think so. Go read your book or notes or
whatever you have because all the answers will be in there. The teacher will not ask you a question on a subject
you have no prior knowledge of.

[svn:fx-trunk] 8575: Some fixes to deeplinking

Similar Messages

Maybe you are looking for