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]
