Well, I guess I made an assumption here... I assumed you would have enough information to construct a URL using localhost as the server name. I guess that's not a safe assumption in this case.
So let me understand this scenario further... you are sending a WAR out to a client, right? When the WAR runs, doesn't it always expand to the same path? Echoing the name of the WAR, right? Are you saying the client can change the name of the WAR at will, or that it's by design different for each client? (Yes, the snow is getting VERY old already here in PA too... I don't know how people who live in Minnesota and Chicago and the other normally cold weather states bear it!) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, January 26, 2005 2:20 pm, David G. Friedman said: > Frank, > > How would you know a URL to check inside the plugIn without editing any > files? If you could get that from within the plugIn, you wouldn't need to > send a request. Where would you send it? To localhost but with what > context? See where my snow-covered (yep, another Boston,MA,USA storm) > thinking is going with this? > > -David, having a 'bald' moment > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 26, 2005 2:13 PM > To: user@struts.apache.org > Subject: RE: PlugIn and the base URL > > > I would personally couple this with the thread idea I mentioned earlier... > Spawn a thread to send through a request after a few seconds to check > baseURL or set it as appropriate. That would remove the user interaction > aspect, and probably would get everything set up quicker, at least in a > known amount of time. > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > On Wed, January 26, 2005 1:52 pm, Wiebe de Jong said: >> Hey David, that is a great idea. >> >> Let me build on it a bit... >> >> When the .war file is deployed, the baseURL property will be blank. >> >> When the application starts up, it will check this property. If the >> property >> is blank, the app will be in 'inactive' state and the only menu item >> presented to the user is 'Activate'. The action for 'Activate' will read >> the >> URL from the response and set the property. The application is now in >> the >> 'active' state and operating normally. >> >> The next time the application starts up and checks the property, it is >> not >> blank so the app is 'active'. >> >> The activate action could do a couple of other things as well, such as >> record the activation time (if you need it for billing) or fire off a >> message to a licensing or billing server (for hosted apps, etc). >> >> Wiebe de Jong >> >> >> -----Original Message----- >> From: David G. Friedman [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, January 26, 2005 10:33 AM >> To: Struts Users Mailing List >> Subject: RE: PlugIn and the base URL >> >> A Devil's Advocate says: >> >> I agree with the theory that the webapp Context name within the >> application >> server "/myapp" should be available to the servlet but not the >> host/port/etc. Why? Imagine you work on a project like mine where you >> are >> using virtual host capability to map various paths on various virtual >> hosts >> to your one Java webapp (one instance for all clients). The startup >> information you would obtain, in that situation, on the host and server >> port >> would be wrong. Only the request object would have the correct data. >> >> With that in mind, the Devil's Advocate suggests: >> >> Can you provide a plug-in to check a file for the information you >> require? >> On first run, there would be no data so let them, upon first >> installation, >> run an action. That action could see if said file exists and, if not, >> put >> it's url information (from the request) into that file (and this one >> time >> into that class's class instance data). If the file exists, the action >> could politely return a page explaining the requested function is not >> available (to prevent someone from potentially screwing things up by >> running >> that action again). >> >> Regards, >> David, the devil's advocate today. >> >> -----Original Message----- >> From: Martin Wegner [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, January 26, 2005 12:53 PM >> To: Struts Users Mailing List >> Subject: RE: PlugIn and the base URL >> >> Agreed. That approach works more often than not. Except in this case. >> The client of the WS does indeed use the URL that is sent back. That is >> part of the overal protocol. So it has to be a valid URL that reaches >> the >> WS inside of my Struts app. >> >> One could argue that the real problem is within Axis, which does not >> provide any HTTP details to the WS call dispatcher. If I had access to >> that info I could stuff it into the WS DOM response and not bother with >> the Struts PlugIn. Sigh. >> >> --Marty >> >> --- "Varley, Roger" <[EMAIL PROTECTED]> wrote: >> >>> > >>> > The WS response has to contain the URL that was used to >>> > access the WS. >>> > This is a requirement of the XML Schema that defines the WS response >>> > payload. I have no control over this. >>> > >>> >>> I know this might be stupid, but whenever I see an odd requirement like >>> this my first experiment is to see what happens if I pass something >>> that >>> is a valid URL but doesn't actually point anywhere. In this way you >>> could simply "hard-code" a string value into your plugin. It wouldn't >>> be >>> the first time I've come across a "mandatory" requirement that doesn't >>> actually do anything :) >>> >>> Regards >>> Roger >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
