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]
