Surely you can have your application issue the request once a SOAP knocking is heard?
Jack On Wed, 26 Jan 2005 12:56:50 -0800 (PST), Martin Wegner <[EMAIL PROTECTED]> wrote: > David, > > Right. I cannot guarantee that any human will hit the web server before > an SOAP based application contacts the WS. So I am still stuck with the > same problem: no access to a Request object until a human points their > browser at the container. > > --Marty > > --- "David G. Friedman" <[EMAIL PROTECTED]> wrote: > > > Martin, > > > > Are you saying you can't even do my suggestion, which would only be > > required > > the very FIRST time the app is deployed? Further restarts or reboots, > > etc., > > wouldn't need that initial url with what I suggested. Not as long as > > you > > hooked the special first-time(only) url to hit the plugins' init methods > > once the first initialization occurred over the web. Reinvoking the > > plugIn > > inits from that primary deployment URL shouldn't be that hard in that > > case. > > Again, not as long as you saved the URL in a file so future > > restarts/reboots > > would not need that manual (first-time) URL ever again. > > > > Regards, > > David > > > > -----Original Message----- > > From: Martin Wegner [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, January 26, 2005 3:39 PM > > To: Struts Users Mailing List > > Subject: RE: PlugIn and the base URL > > > > > > > > Yes, this is the scenario. The web container could change, the port > > number could change and the WAR filename could change. So the PlugIn > > needs to divine the URL completely at run time. Which is why it has > > stumped me to date. > > > > > > --Marty > > > > --- [EMAIL PROTECTED] wrote: > > > > > 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] > > > > > > --------------------------------------------------------------------- > > 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] > > -- ------------------------------ "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ ----------------------------------------------- "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
