• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: EOClientApplicationSupport weirdness
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EOClientApplicationSupport weirdness


  • Subject: Re: EOClientApplicationSupport weirdness
  • From: Lachlan Deck <email@hidden>
  • Date: Wed, 26 Mar 2008 12:27:18 +1100

Hi there,

On 26/03/2008, at 8:42 AM, John Pollard wrote:
All I can say is that this affects our JC application too. We allow the connection URL to be set in a login window, but any changes after the first connection attempt are ignored; the original URL seems to stick as you say. This problem has been annoying for a long time but I always put it down to the fact that this com .webobjects .eoapplication.client.EOClientApplicationSupport.main(...) method was obviously not meant to be used in the way us non-nibber JC people use it to establish the client/server connection. I think its time we were given an initialisation method to call instead of hijacking this main() method.
John


On 24 Mar 2008, at 16:21, Florijan Stamenkovic wrote:

just in case I am wrong about my loop being OK, the code is below.

// try to connect to all given urls
for(String url : urls){
url = url.trim();
Log.out("Will try to establish a connection to application server at: " + "\""+url+"\"");


try{
// if connection has been established, return
if(connected) return;

// try to connect
com.webobjects.eoapplication.client.EOClientApplicationSupport.main(
new String[]{"-applicationURL", url});
// wait for the specified timeout
synchronized(monitor){
monitor.wait(TIMEOUT);
}
// if connection has been established, return
if(connected) return;
}catch(Throwable th){}
}

It does look to me as though EOClientApplicationSupport.runStartupDialogs(NSDictionary) is supposed to do this for you. i.e., giving the client the opportunity to try a different url.


Is that not the case?

If not, you might be able to fix this by doing one or both of the following... inbetween each attempt:
-------
(a)
// fix the merging of arguments so old ones don't stick in favour of new ones
NSMutableDictionary args = new NSMutableDictionary();
if ( EOApplication.arguments() != null )
args.addEntriesFromDictionary( EOApplication.arguments() );
args.setObjectForKey( url, ApplicationURLProperty );
EOApplication.setArguments( args );
// and just to be safe:
NSProperties._setProperty( ApplicationURLProperty, url );
-------
(b)
Set channelClassName property and provide a subclass of EOHTTPChannel. If you don't trust the applicationURL provided, grab the next attempt from your main application instance.


with regards,
--

Lachlan Deck

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • [SOLVED] Re: EOClientApplicationSupport weirdness
      • From: Florijan Stamenkovic <email@hidden>
References: 
 >EOClientApplicationSupport weirdness (From: Florijan Stamenkovic <email@hidden>)
 >Re: EOClientApplicationSupport weirdness (From: John Pollard <email@hidden>)

  • Prev by Date: Re: EOEditingContext for JUnit
  • Next by Date: WO 5.4 Linux Deployment
  • Previous by thread: Re: EOClientApplicationSupport weirdness
  • Next by thread: [SOLVED] Re: EOClientApplicationSupport weirdness
  • Index(es):
    • Date
    • Thread