[svn:bz-trunk] 14655: Fix hostname in failing MXUnit proxy service tests.

Revision: 14655
Revision: 14655
Author:   [email protected]
Date:     2010-03-09 18:41:52 -0800 (Tue, 09 Mar 2010)
Log Message:
Fix hostname in failing MXUnit proxy service tests. The hostname flexteam.macromedia.com no longer resolves. Changed the tests to just use flexteam as the hostname. We probably shouldn't have tests that rely on flexteam but we can worry about that later.
Modified Paths:
    blazeds/trunk/qa/apps/qa-regress/testsuites/mxunit/tests/proxyService/202863/bug202863Doc Lit.mxml
    blazeds/trunk/qa/apps/qa-regress/testsuites/mxunit/tests/proxyService/202863/bug202863Rpc Enc.mxml

Similar Messages

[svn:bz-trunk] 7681: Fix bunch of failing config tests on BlazeDS/ trunk by removing javax.servlet. UnavailableException from the expected error string.

Revision: 7681
Author:   [email protected]
Date:     2009-06-09 11:44:36 -0700 (Tue, 09 Jun 2009)
Log Message:
Fix bunch of failing config tests on BlazeDS/trunk by removing javax.servlet.UnavailableException from the expected error string.
Modified Paths:
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/destination/IncorrectRootElement Test/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/AdaptiveServerT oClient/AdaptiveFrequencyTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/AdaptiveServerT oClient/FrequencyStepSizeTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/AdaptiveServerT oClient/MaxQueueSizeTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/DestinationWith NoChannelTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/DestinationWith NoIDTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/jms/InvalidAckn owledgeModeTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/jms/InvalidDeli veryModeTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/jms/InvalidDest inationTypeTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/jms/InvalidMess ageTypeTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/jms/NoConnectio nFactoryTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/jms/NoJNDINameT est/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/throttle/thrott leInbound/InvalidBufferPolicyTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/throttle/thrott leInbound/InvalidConflatePolicyTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/throttle/thrott leInbound/UnknownInboundPolicyTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/throttle/thrott leInbound/frequencies/McfGreaterthanMfTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/throttle/thrott leOutbound/InvalidBufferPolicyTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/throttle/thrott leOutbound/InvalidConflatePolicyTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/throttle/thrott leOutbound/InvalidErrorPolicyTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/throttle/thrott leOutbound/UnknownOutboundPolicyTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/throttle/thrott leOutbound/frequencies/McfGreaterthanMfTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/validation/nonE xistingValidatorTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/validation/same ExplicitTypeValidatorTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/validation/same TypeValidatorTest/error.txt
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/validation/wron gTypeValidatorTest/error.txt

[svn:bz-trunk] 18907: Fix failing MBean test.

Revision: 18907
Revision: 18907
Author:   [email protected]
Date:     2010-12-01 11:55:22 -0800 (Wed, 01 Dec 2010)
Log Message:
Fix failing MBean test. The name of the web application changed in the web.xml file for the webapp causing the test to break. I updated the test to use the new webapp name which is "Flex QA Web Application". There are a few more MBean tests that are failing likely due to the same problem. I will update these as I have time unless someone else wants to tackle this.
Modified Paths:
    blazeds/trunk/qa/apps/qa-regress/testsuites/mxunit/tests/MBean/jmx/MBeanServerGateway.mxm l

Pierre-Charles David a écrit :
> Hi,
>
> I've got a very strange issue and I don't know where to look for to fix
> it. In some Eclipse configuration I use, SWTBot does not work at all: it
> fails the very first method with a WidgetNotFoundException.
[snip]
Well, I found the issue:
SWTBot declares a dependency to org.apache.log4j but does not indicate
any specific version. However, it uses APIs which only appeared in log4j
1.2.12 (at least Logger.trace(), maybe others).
In the Eclipse installation I have which did not work ("Topcased RCP"),
there was a bundle which provided the org.apache.log4j package, but
using log4j version 1.2.8. As it happens, Eclipse decided to provide
this one to SWTBot instead of other versions available from different
bundles (1.2.12 and 1.2.15). The test failed with an internal
NoSuchMethodError, which must have been caught by some code and wrapped
as the WidgetNotFoundException I saw.
Removing the plugin with log4j 1.2.8 from the test's run configuration
solves the issue.
I have opened bug #286527 about this.

[svn:bz-trunk] 18908: Fix failing MBean tests.

Revision: 18908
Revision: 18908
Author:   [email protected]
Date:     2010-12-01 11:58:31 -0800 (Wed, 01 Dec 2010)
Log Message:
Fix failing MBean tests. The name of the web application changed in the web.xml file for the webapp causing the test to break. I updated the test to use the new webapp name which is "Flex QA Web Application".
Modified Paths:
    blazeds/trunk/qa/apps/qa-regress/testsuites/mxunit/tests/MBean/messagingservice/Streaming AMFEndpointMBean.mxml
    blazeds/trunk/qa/apps/qa-regress/testsuites/mxunit/tests/MBean/messagingservice/Streaming HTTPEndpointMBean.mxml

[svn:bz-trunk] 23072: - fixed failing test on J2EE version based on . Net changes.

Revision: 23072
Revision: 23072
Author:   [email protected]
Date:     2011-10-20 06:59:14 -0700 (Thu, 20 Oct 2011)
Log Message:
- fixed failing test on J2EE version based on .Net changes.
Modified Paths:
    blazeds/trunk/qa/apps/qa-regress/testsuites/mxunit/tests/remotingService/dataTypes/Boolea nTypesTest.mxml

The first thing I would do is go the the CF administrator and
make sure all of your DEBUG information is being displayed. By
default, some isn't. A lot of times when you get a .net error and
it tells you nothing, go to the area below Execution Time and there
is an exceptions area. That is usually where .NET errors are
returned (system.nullReferenceException for example).
When passing in strings, I typically assign it to a variable,
then pass in the variable. It shouldn't matter, but sometimes I
have run into issues with passing a string in. In your second
object, look at the date object. The Coldfusion date object and the
.Net date object are not the same. Hope this helps.

[svn:bz-trunk] 5137: Fix failing security tests on BlazeDS/ trunk by using a remote object to invalidate the FlexSession at the end of each test method which should cause each test method to run with a new /clean session.

Revision: 5137
Author: [email protected]
Date: 2009-03-02 10:28:59 -0800 (Mon, 02 Mar 2009)
Log Message:
Fix failing security tests on BlazeDS/trunk by using a remote object to invalidate the FlexSession at the end of each test method which should cause each test method to run with a new/clean session. It looks like some test methods were leaving some things in a bad state which was causing the next test that ran to fail. These may be legitimate bugs/issues so we should investigate further to see what sequence of events gets things into a bad state but for these tests we want all of the test methods to run in isolation.
Modified Paths:
blazeds/trunk/qa/apps/qa-manual/WEB-INF/flex/services-config.mods.xml
blazeds/trunk/qa/apps/qa-regress/WEB-INF/flex/remoting-config.mods.xml
blazeds/trunk/qa/apps/qa-regress/testsuites/mxunit/tests/messagingService/security/stream ing-amf/JMSAuthSendSubscribeConstraintTest.mxml
blazeds/trunk/qa/apps/qa-regress/testsuites/mxunit/tests/messagingService/security/stream ing-amf/MessagingAuthProSendTest.mxml
blazeds/trunk/qa/apps/qa-regress/testsuites/mxunit/tests/messagingService/security/stream ing-http/JMSAuthSendSubscribeConstraintTest.mxml
blazeds/trunk/qa/apps/qa-regress/testsuites/mxunit/tests/messagingService/security/stream ing-http/MessagingAuthProSendTest.mxml
Added Paths:
blazeds/trunk/qa/apps/qa-regress/WEB-INF/src/qa/messaging/SessionManager.java

In general theory, one now has the Edit button for their posts, until someone/anyone Replies to it. I've had Edit available for weeks, as opposed to the old forum's ~ 30 mins.
That, however, is in theory. I've posted, and immediately seen something that needed editing, only to find NO Replies, yet the Edit button is no longer available, only seconds later. Still, in that same thread, I'd have the Edit button from older posts, to which there had also been no Replies even after several days/weeks. Found one that had to be over a month old, and Edit was still there.
Do not know the why/how of this behavior. At first, I thought that maybe there WAS a Reply, that "ate" my Edit button, but had not Refreshed on my screen. Refresh still showed no Replies, just no Edit either. In those cases, I just Reply and mention the [Edit].
Also, it seems that the buttons get very scrambled at times, and Refresh does not always clear that up. I end up clicking where I "think" the right button should be and hope for the best. Seems that when the buttons do bunch up they can appear at random around the page, often three atop one another, and maybe one way the heck out in left-field.
While I'm on a role, it would be nice to be able to switch between Flattened and Threaded Views on the fly. Each has a use, and having to go to Options and then come back down to the thread is a very slow process. Jive is probably incapable of this, but I can dream.
Hunt

[svn:bz-trunk] 23083: Fix failing MXUnit test.

Revision: 23083
Revision: 23083
Author:   [email protected]
Date:     2011-10-21 07:11:32 -0700 (Fri, 21 Oct 2011)
Log Message:
Fix failing MXUnit test.
Modified Paths:
    blazeds/trunk/qa/apps/qa-regress/testsuites/mxunit/tests/remotingService/dataTypes/DateTy pesTest.mxml

[svn:bz-trunk] 9665: Fix minor typo in errors.properties file.

Revision: 9665
Author:   [email protected]
Date:     2009-08-26 14:13:27 -0700 (Wed, 26 Aug 2009)
Log Message:
Fix minor typo in errors.properties file. Change "wilcard" to "wildcard" in the following error string.
10560=Attempt to subscribe to the subtopic, '''', on destination, '''', that does not allow wilcard subtopics failed.
Checkintests: passed
Modified Paths:
    blazeds/trunk/modules/common/src/flex/messaging/errors.properties
    blazeds/trunk/qa/apps/qa-regress/testsuites/mxunit/tests/messagingService/dynamicDestinat ions/subtopicsEnabledWildcardsNotAllowed.mxml

onearm wrote:
Svn revision 442 doesn't compile on Arch64:
[ 4%] [ 5%] Building CXX object src/CMakeFiles/guayadeque.dir/AlListBox.o
Building CXX object src/CMakeFiles/guayadeque.dir/ArListBox.o
In file included from /tmp/yaourt-tmp-gianluca/aur-guayadeque-svn/guayadeque-svn/src/guayadeque/Trunk/src/LastFMPanel.h:25,
from /tmp/yaourt-tmp-gianluca/aur-guayadeque-svn/guayadeque-svn/src/guayadeque/Trunk/src/MainFrame.h:27,
from /tmp/yaourt-tmp-gianluca/aur-guayadeque-svn/guayadeque-svn/src/guayadeque/Trunk/src/AlListBox.cpp:27:
/tmp/yaourt-tmp-gianluca/aur-guayadeque-svn/guayadeque-svn/src/guayadeque/Trunk/src/PlayerPanel.h:25:28: error: AutoScrollText.h: No such file or directory
[ 7%] Building CXX object src/CMakeFiles/guayadeque.dir/ArrayStringArray.o
[ 8%] Building CXX object src/CMakeFiles/guayadeque.dir/AudioScrobble.o
make[2]: *** [src/CMakeFiles/guayadeque.dir/AlListBox.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [src/CMakeFiles/guayadeque.dir/all] Error 2
make: *** [all] Error 2
Thanks for the bug report. It was a test i was doing but finally decided to not include it but left this line by error.
It have been fixed in svn 443.
Thanks again

[svn:fx-trunk] 9329: Fixing openDuration on Tree.

Revision: 9329
Author:   [email protected]
Date:     2009-08-14 17:07:31 -0700 (Fri, 14 Aug 2009)
Log Message:
Fixing openDuration on Tree. The issue was that a call to UIComponent.suspendBackgroundProcessing() wasn?\226?\128?\153t being respected by LayoutManager, now that it doesn?\226?\128?\153t use UIComponent.callLater(). The fix was for LayoutManager to look at UIComponentGlobals.callLaterSuspsendCount. There are probably other ways to fix this bug because all the tweening in Tree seems very hokey, but given that UIC.suspendBackgroundProcessing() should be respected by LayoutManager, this seemed like the right fix.
QE notes: We should add tests for openDuration
Doc notes: -
Bugs: SDK-21752
Reviewer: Alex
Tests run: checkintests, mustella Tree
Is noteworthy for integration: No
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-21752
Modified Paths:
    flex/sdk/trunk/frameworks/projects/framework/src/mx/managers/LayoutManager.as

ould wrote:
I have done the hard work for you. My HTPC is pretty barebones so it was relatively easy to roll back all the packages that depend on libjpeg>7 with older versions. I then compiled the xbmc-svn package using that system. Slow downs are gone and I have uploaded the package to hotfile here:
http://hotfile.com/dl/13546051/021f9c9/ … ar.gz.html
This is for 32-bit. You will need the libjpeg6 package from AUR installed. I have tested it on two systems, my main system which has both libjpeg7 and the AUR libjpeg6 installed and on my htpc which has only the libjpeg6 along with the rolled back dependancies. Works good on both systems.
Hope that helps!
Kevin
Thanks ould!! You got it working with libjpeg6 again!
I had to upgrade libcdio again so now I lost dvd support. It's not easy to use the svn version.
If you could compile the build against libcdio 0.80 I'd be forever grateful... If you've got the time.
Last edited by Perre (2009-09-26 17:09:04)

[svn:bz-trunk] 10281: Fix for BLZ-343.

Revision: 10281
Author:   [email protected]
Date:     2009-09-15 15:30:27 -0700 (Tue, 15 Sep 2009)
Log Message:
Fix for BLZ-343.
Move common code from AbstractAmfInput back to the subclasses Amf0Input and Amf3Input. A proxy instance was being created locally in the superclass method, but was unavaliable to the remaining code in the subclasses. The subclasses were therefore using the wrong proxy to unwrap the value, which caused problems when deserializing Enums.
reviewed by Mete
checkintests pass (minus 2 that have been failing intermittently)
Ticket Links:
    http://bugs.adobe.com/jira/browse/BLZ-343
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
    blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/messagingService/dataTypesTest/E numTypeTest.mxml
    blazeds/trunk/qa/apps/qa-regress/testsuites/mxunit/tests/remotingService/dataTypes/EnumTy peTest.mxml

[svn] 3379: This should fix the startupJMSDestTest. mxml and runtimeJMSDestTest.mxml tests that are currently failing on JBoss.

Revision: 3379
Author: [email protected]
Date: 2008-09-26 10:47:35 -0700 (Fri, 26 Sep 2008)
Log Message:
This should fix the startupJMSDestTest.mxml and runtimeJMSDestTest.mxml tests that are currently failing on JBoss. RuntimeJMSDestination.java was not properly setting the jndi name for the ConnectionFactory and DestinationJNDIName on JBoss. Added a new function to get the application server type.
Modified Paths:
blazeds/branches/3.0.x/qa/apps/qa-regress/WEB-INF/src/runtimeconfig/components/RuntimeJMS Destination.java

Cleoriff wrote:
So...if my Note 3 was bought sim free and unlocked would I expect to get Lollipop sooner?
(I really am unsure of how this works)
It's likely that would be correct - typically speaking, open market handsets can get updates sooner than network supplied ones, though there are occasions where our network update can be out before the open market ones. As you can see sometimes the 'logistics' of software updates can be a little topsy-turvy.
Just to clarify though, it doesn't look like Samsung have started pushing any updates out for the Note 3 in the UK yet - a Google search seems to suggest it may be pushing out in Russia (we have no official details on any rollouts outside UK) which is good news but it can take vendors weeks and into the month(s) before their rollouts spread across all markets. It's not unusual for vendors to launch updates into a small number of markets to test the waters several days/weeks before they consider a full rollout - this gives them an opportunity for real-world customer usage to see if there's any major issues with it.
Another thing to consider are bugs - while an extreme example, take the Note II for instance - the open market update had a rather large Bluetooth bug that caused many issues for people who used Bluetooth devices. The update that we got Samsung to push out for us included a fix for this bug.
Long story short: While I understand the need/desire for many to get the update ASAP/immediately, it doesn't always pay off. Bugs do happen and sometimes they're found soon enough in open market updates that we can get them patched for our own update. So there are of course merits to both :-)

[svn:bz-trunk] 23023: Fix unterminated string literal.

Revision: 23023
Revision: 23023
Author:   [email protected]
Date:     2011-10-17 08:00:07 -0700 (Mon, 17 Oct 2011)
Log Message:
Fix unterminated string literal.
Modified Paths:
    blazeds/trunk/qa/apps/qa-regress/testsuites/mxunit/tests/remotingService/dataTypes/DeferI nstantiationTest.mxml

[svn:bz-trunk] 14778: fix the tests by checking all possible return text.

Revision: 14778
Revision: 14778
Author:   [email protected]
Date:     2010-03-16 09:14:53 -0700 (Tue, 16 Mar 2010)
Log Message:
fix the tests by checking all possible return text.
Modified Paths:
    blazeds/trunk/qa/apps/qa-regress/testsuites/mxunit/tests/proxyService/httpservice/amfchan nel/hs_resultformat.mxml
    blazeds/trunk/qa/apps/qa-regress/testsuites/mxunit/tests/proxyService/httpservice/httpcha nnel/hs_resultformat.mxml

I believe that plugins rely on the libraries being located in a specific location. The installer can place these libraries in the specific location or some other installer can do that. You can create code that scans the library directly to "learn" what packages/libraries are available. Then you would build the path to that VI and open the reference to it.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

[svn:bz-trunk] 13884: Fix some of the checkstyle warnings, no code change.

Revision: 13884
Revision: 13884
Author:   [email protected]
Date:     2010-01-29 09:23:18 -0800 (Fri, 29 Jan 2010)
Log Message:
Fix some of the checkstyle warnings, no code change.
Modified Paths:
    blazeds/trunk/modules/core/src/flex/messaging/io/amf/client/AMFHeaderProcessor.java
    blazeds/trunk/modules/core/src/flex/messaging/io/amf/client/exceptions/ClientStatusExcept ion.java
    blazeds/trunk/modules/core/src/flex/messaging/io/amf/client/exceptions/ServerStatusExcept ion.java
    blazeds/trunk/modules/core/src/flex/messaging/io/amf/client/exceptions/package-info.java
    blazeds/trunk/modules/core/src/flex/messaging/messages/AcknowledgeMessage.java
    blazeds/trunk/modules/core/src/flex/messaging/messages/BatchableMessage.java
    blazeds/trunk/modules/core/src/flex/messaging/messages/MessagePerformanceInfo.java
    blazeds/trunk/modules/core/src/flex/messaging/security/LoginCommandExt.java
    blazeds/trunk/modules/core/src/flex/messaging/services/AuthenticationService.java
    blazeds/trunk/modules/core/src/flex/messaging/services/messaging/MessageFrequency.java
    blazeds/trunk/modules/core/src/flex/messaging/services/messaging/RemoteMessageClient.java
    blazeds/trunk/modules/core/src/flex/messaging/util/DoubleUtil.java
    blazeds/trunk/modules/core/src/flex/messaging/util/concurrent/Executor.java
    blazeds/trunk/modules/core/src/flex/messaging/validators/ClassDeserializationValidator.ja va
    blazeds/trunk/modules/core/src/flex/messaging/validators/DeserializationValidator.java
    blazeds/trunk/modules/opt/src/tomcat/flex/messaging/security/TomcatLogin.java
    blazeds/trunk/modules/proxy/src/flex/management/runtime/messaging/services/http/HTTPProxy DestinationControl.java
    blazeds/trunk/modules/proxy/src/flex/management/runtime/messaging/services/http/package-i nfo.java
    blazeds/trunk/modules/proxy/src/flex/messaging/services/http/httpclient/package-info.java
    blazeds/trunk/modules/proxy/src/flex/messaging/services/http/package-info.java
    blazeds/trunk/modules/proxy/src/flex/messaging/services/http/proxy/AccessFilter.java
    blazeds/trunk/modules/proxy/src/flex/messaging/services/http/proxy/ErrorFilter.java
    blazeds/trunk/modules/proxy/src/flex/messaging/services/http/proxy/ProxyContextFilter.jav a
    blazeds/trunk/modules/proxy/src/flex/messaging/services/http/proxy/ProxyUtil.java
    blazeds/trunk/modules/proxy/src/flex/messaging/services/http/proxy/package-info.java
    blazeds/trunk/modules/remoting/src/flex/management/runtime/messaging/services/remoting/ad apters/package-info.java
    blazeds/trunk/modules/remoting/src/flex/management/runtime/messaging/services/remoting/pa ckage-info.java
    blazeds/trunk/modules/remoting/src/flex/messaging/services/remoting/adapters/package-info .java
    blazeds/trunk/modules/remoting/src/flex/messaging/services/remoting/package-info.java

[svn:bz-trunk] 23085: Fix test to explicitly remove an event listener after the test is finished .

Revision: 23085
Revision: 23085
Author:   [email protected]
Date:     2011-10-21 07:49:33 -0700 (Fri, 21 Oct 2011)
Log Message:
Fix test to explicitly remove an event listener after the test is finished. Not doing this was causing the test to throw an RTE.
Modified Paths:
    blazeds/trunk/qa/apps/qa-regress/testsuites/mxunit/tests/messagingService/security/stream ing-amf/MessagingAuthProSendTest.mxml

Thanks for the ideas regarding beforeInvoke, Ben. I will try to check that out. In my situation, here's essentially how my script is working...
BeforeSave is invoked.
Script makes a change to the document, which should be captured in the saved file.
Document saves.
Document appears saved for a moment, and then appears unsaved (asterisk in the document title).
My biggest problem is that this behavior isn't consistent. I have dozens of users, all running the same script, and the problem only occurs with certain users and at random times. I can move a problematic document from a user's machine to a different machine, and the problem doesn't occur there. It's very difficult to troubleshoot because I can't reproduce it consistently.

[svn:bz-trunk] 14655: Fix hostname in failing MXUnit proxy service tests.

Similar Messages

Maybe you are looking for