This won't work becuase Struts is configuring the business objects behind the WS. This solution, while correct, relies on a human logging into the web site in order to trigger the action. This is not the case in this app. The WS is much more active than the web app.
But it is a very good idea for a situation where human interaction was the driver. --Marty --- Wiebe de Jong <[EMAIL PROTECTED]> wrote: > 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]
