Maybe one better suggestion... How about distributing an executable JAR that contains a simple Swing client... This client runs when the JAR is executed, asks for the URL, writes out the config file, updates the JAR, renames it to WAR and even asks for the webapp directory and copies the WAR there. Kind of a little installer that deals with everything in a fairly nice way. Still needs a human to provide the URL, but I don't see a way around that.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Martin Wegner 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
