RE: PlugIn and the base URL
Definitely too difficult to communicate using email! Please read the scenario I was framing my response under. As an application that is bought, you do not have control over the environment it will be installed in so firewalls do come to play in my mind. This thing has been beaten to death! I think a Filter was the first thing we suggested anyway but that was shot down hence my framing of the problem domain in what I thought was happening where these other concerns would start coming up. Happy to hear that you got what you needed Martin! Regards...djsuarez -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Friday, January 28, 2005 9:49 AM To: Struts Users Mailing List Cc: Martin Wegner Subject: Re: PlugIn and the base URL On Fri, 28 Jan 2005 08:02:46 -0600, David Suarez <[EMAIL PROTECTED]> wrote: > Just the same, it's > likely not a problem for your server to figure out where the request > came from if that is needed for the protocol (the receiver of the > initial message). It's the callback that you have a problem with and it > sounds like it's for a reason... It doesn't make sense to assume that > the web service installed on the client inside some network will be > reachable from the external network. If this is what you're doing, > configuration (having the client app user set the URL) is the only way > to set it up because they (the client) will likely need to open up some > incoming requests that they normally would not allow through their > firewalls anyway. Not to mention whatever you grab would be the > "internal" ip addresses. If your server grabs the ip from the request, > it is likely to a proxy somewhere and not to your app. This would seem to make sense, I guess, David S., but it does not. The ip address you want is the one that a foreign user should use to get to you and if you send a request, as I suggested, via a mini-browser in your PlugIn, the TCP/IP HTTP protocols will send to the recipient the IP address needed to reach your machine. Then, that machine can send back to you what that is. I know this works because I do it all the time. You can determine the same thing by sending the message to another machine on another port in the same intranet. Jack -- -- "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]
Re: PlugIn and the base URL
Just so everyone is knowingly on the same page, the basics are at http://webserver.cpg.com/ws/3.4/. Jack -- -- "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. We are poor . . . but we are free." ~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]
Re: PlugIn and the base URL
On Fri, 28 Jan 2005 11:15:35 -0600, Eddie Bush <[EMAIL PROTECTED]> wrote: > See Frank's post on the web service. He expressed it more eloquently > than I did. But, Frank and I are in agreement. If you are not talking about the Web, then you are saying that the solution is not a solution to an area where there is no problem anyway. We were not talking about Intranets. > Names, depending upon how the web server is configured, could matter a > great deal. Name-based virtual hosts, for example ... Actually, Eddie, if you follow the logic in this situation through thoroughly you will find that this sort of configuration is completely irrelevant to this issue. The problems regarding finding machines in this area are not reflexive. Jack -- -- "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]
Re: PlugIn and the base URL
On Fri, 28 Jan 2005 09:03:07 -0800 (PST), [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > While I absolutely acknowledge the cleverness of this solution, it's not one > I would personally employ. Making a server application dependent on another > server for startup configuration strikes me as quite a hack (albeit a clever > one!) There is no need to make the dependency. You can give your clients a choice: configure or not. However, if there is no choice, then this is the way to go, I think. As Eddie suggested, I think, what you need depends on your business. I have security situations where I require that this is done for all Internet calls. This not only requires that the host get the IP address from the external server but that the IP address is regularly or irregularly but frequently switched and that the client must access the external server too in order to reach the host at whateer the present IP address happens to be with a token from the external server that certifies that the client has done this. This may sound bizarre, but there are all sorts of requirements out there. I am sure that each of us has our own stories of the peculiarities of our own actual business. > Careful! Here at work we are using Web Services quite a bit, but so far, > very few of them go outside our network. We expose a lot of shared > components and systems as services, but they are only available to other > internal applications. > > I don't think that changes your basic premise though... Chances are, if you > are using this two-server initialization scheme, your clearly going to make > sure they can talk to each other, regardless of network topology. Yes! I think this is what Eddie was thinking too, but in the present context that is not what we were talking about, or there would not be all this worry about URLs, etc., I assume. If the problem were internal to an intranet, none of this discussion would make much sense. There is a firewall issue to the outside (Internet) too, but that is the port issue, which was covered, revisited. I personally would not think of intranet services as "Web" services, but I guess that is not really a bad way to speak. As long as we understand each other, this would not matter. I think there is a chance of confusion, however, if we think of intranets as the "Web". That is not much of a "Web". While I don't depend too much on dictionary itemizations of usages (NOT "definitions, PLEASE -- linguistics is not biology) in volatile areas of speech, the following is the way I talk and is from Meriam-Webster online (www.m-w.com): Main Entry: World Wide Web Function: noun : a part of the Internet designed to allow easier navigation of the network through the use of graphical user interfaces and hypertext links between different addresses -- called also Web Anyway, Frank, I do see your point and I think that it is great Martin got his answer from Kishore and AXIS. Since he is doing SOAP, that is the place to get it alright. Jack -- -- "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]
Re: PlugIn and the base URL
Lo, Eddie, See infra: > How many different host/port combinations are the applications you use > this strategy in deployed to? Thousands. > In the environment I "live", apps deploy on multiple servers (always > 2+ for high availability), and are likely to be accessed by a > different (non-standard) port for each instance. How can you, given > that criteria, construct a URL that will work? Depends on how you do things. Generally speaking, however, the issues are not so diverse as you might think. I won't talk about some specialized and difficult issues that you are very unlikely to face. Whatever URLs you are using are all resolving to the same IP address and then are being allocated internally. The actual "English" URL never made a difference anyway. > I disagree. It can make a huge amount of sense to have a web service > that exists only behind a firewall. You just haven't seen the > usefulness of it yet ... Nope, I haven't. The sense that I was talking about had a web service firewalling those that want to use it. That is what was not useful in the "scenario" I was talking about. That is almost tautological, isn't it? This is the only sense in which a firewall could impact the suggestion I was making. Suppose for example, that you have a firewall that keeps machines external to an intranet from accessing the intranet. If you don't want those people accessing your machines, then that hardly causes a problem for this solution. The comment I was responding to, which is an important context to my statements was David's note as follows: It doesn't make sense to assume that the web service installed on the client inside some network will be reachable from the external network. If this is what you're doing, configuration (having the client app user set the URL) is the only way to set it up because they (the client) will likely need to open up some incoming requests that they normally would not allow through their firewalls anyway. Not to mention whatever you grab would be the "internal" ip addresses. If your server grabs the ip from the request, it is likely to a proxy somewhere and not to your app. If I understand David, and maybe I don't, he is thinking that internal routing needs to be known by outside clients, in addition to the "external" IP addresses. Actually, there are no "internal" IP addresses. The Internet Protocol is external only. Right? Now, if you are talking about intranets that excluded access from the Internet, then you are talking about something totally different than the entire conversation and I was not addressing that issue. I think I was okay to assume that all this talk about URLs was about Internet and not intranet addresses. So, Eddie, I assume you are talking about some use of web services outside the context of the discussion when you say: It can make a huge amount of sense to have a web service that exists only behind a firewall. You just haven't seen the usefulness of it yet ... The other alternative is that you mean that there is a firewall but that the web service port is not firewalled. If that is the case, then you are talking about an issue that was addressed in detail in the thread and you might have missed. I discussed how to get the proper port, if that is what you are talking about. I guess I should just ask you directly: what in the hay are you talking about? Don't keep it a secret. ;-) Jack -- -- "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]
Re: PlugIn and the base URL
While I absolutely acknowledge the cleverness of this solution, it's not one I would personally employ. Making a server application dependent on another server for startup configuration strikes me as quite a hack (albeit a clever one!) > It in fact does make sense to assume that a web service installed on > a network will be reachable from an external network. Careful! Here at work we are using Web Services quite a bit, but so far, very few of them go outside our network. We expose a lot of shared components and systems as services, but they are only available to other internal applications. I don't think that changes your basic premise though... Chances are, if you are using this two-server initialization scheme, your clearly going to make sure they can talk to each other, regardless of network topology. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Fri, January 28, 2005 11:21 am, Dakota Jack said: > > On Fri, 28 Jan 2005 08:02:46 -0600, David Suarez > <[EMAIL PROTECTED]> wrote: >> I think the answer here would be configuration is the only way in the >> scenario above. The question is, do you really need the call backs for >> what you're really doing? In the licensing example above, you likely >> only need to send the request to the public server. The public server >> can check and respond if the license is valid. There's no need for it >> to send you a request later. > > > I am not sure at this point David S. what you have tried, but I can > assure you that your conclusion that "configuration is the only way in > this scenario above" is incorrect, because I do this all the time with > no difficulties whatsoever. > > > It doesn't make sense to assume that > the web service installed on the client inside some network will be > reachable from the external network. If this is what you're doing, > configuration (having the client app user set the URL) is the only way > to set it up because they (the client) will likely need to open up some > incoming requests that they normally would not allow through their > firewalls anyway. > > > The firewall issue is different. It is true that if you have the > correct URL or IP address that a caller cannot get through if there is > a firewall blocking the port. But that is a totally separate concern. > It in fact does make sense to assume that a web service installed on > a network will be reachable from an external network. There would > otherwise be no sense at all to having the web service. If you toss > in these firewall issues, you will only be muddying the waters with > irrelevant concerns that are unrelated to this problem. > > I hope that did not sound too preachy. I guess I am just pretty sure > in this area and hope that you all will see I am only trying to help. > I am sure because I have gone through all the problems in one way or > another related to this many times. > > Wasn't Martin the originator of this thread? Maybe you are talking > about a sub-thread issue? > > Jack > > -- > -- > > "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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PlugIn and the base URL
On Fri, 28 Jan 2005 08:21:40 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > I am not sure at this point David S. what you have tried, but I can > assure you that your conclusion that "configuration is the only way in > this scenario above" is incorrect, because I do this all the time with > no difficulties whatsoever. How many different host/port combinations are the applications you use this strategy in deployed to? In the environment I "live", apps deploy on multiple servers (always 2+ for high availability), and are likely to be accessed by a different (non-standard) port for each instance. How can you, given that criteria, construct a URL that will work? > The firewall issue is different. It is true that if you have the > correct URL or IP address that a caller cannot get through if there is > a firewall blocking the port. But that is a totally separate concern. > It in fact does make sense to assume that a web service installed on > a network will be reachable from an external network. There would > otherwise be no sense at all to having the web service. If you toss > in these firewall issues, you will only be muddying the waters with > irrelevant concerns that are unrelated to this problem. I disagree. It can make a huge amount of sense to have a web service that exists only behind a firewall. You just haven't seen the usefulness of it yet ... > I hope that did not sound too preachy. I guess I am just pretty sure > in this area and hope that you all will see I am only trying to help. > I am sure because I have gone through all the problems in one way or > another related to this many times. > > Wasn't Martin the originator of this thread? Maybe you are talking > about a sub-thread issue? > > Jack -- Eddie Bush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PlugIn and the base URL
Kishore, This turns out to be the exact solution that I require. I just extended AxisServlet and scrape off the "requestURL" which is the URL that was used to reach the WS. That did the trick. And again, this illustrates what I consider a flaw in the Axis implementation. If you look through the Axis source code they drag the HTTP Request right to the door step of the dispatcher and then choose to NOT pass it along to the dispatched method. I am not sure why. Surely access to the request would benefit some WS methods. Oh well. Thanks for all of the input. I got a lot of help from this group. Sorry to have taken up so much bandwidth. --Marty --- Kishore Senji <[EMAIL PROTECTED]> wrote: > On Thu, 27 Jan 2005 21:17:07 -0800 (PST), Martin Wegner > <[EMAIL PROTECTED]> wrote: > > David, > > > > Also, as I said early the Axis architecture is such that it does not > > provide any of the information related to the HTTP layer beneath SOAP. > > The only think you know is that your dispatcher gets called. So my > > problem may be considered a limitation in Axis. > > > > Assuming that all your web service requests to Axis contains /axis in > the path for eg(http://company.com/axis/WebService.jws), I guess you > could have a Filter for the url-pattern /axis/* whose job is to take > the path that was requested (eg > http://company.com/axis/WebService.jws) and stick it into your > business objects? Essentially having a Filter instead of a Plugin. So, > when a web service is requested, before the request reaches the > AxisServlet, the Filter would save the URL in the business objects and > your business objects can throw that URL into the response. Wouldn't > this work? > > --Marty > > > > > Martin, since you seem firm on this issue, can we/I ask WHY you need > > > this > > > information in your webapp during initialization? What are you > doing > > > that > > > you cannot set that information per request (HTTP/SOAP) in your > output? > > > (Or > > > use relative URLS of some sort) Knowing WHY, perhaps someone on the > list > > > can > > > suggest an alternate, yet equally effective, solution for the issue. > > > > > > - > > 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]
Re: PlugIn and the base URL
On Fri, 28 Jan 2005 08:02:46 -0600, David Suarez <[EMAIL PROTECTED]> wrote: > I think the answer here would be configuration is the only way in the > scenario above. The question is, do you really need the call backs for > what you're really doing? In the licensing example above, you likely > only need to send the request to the public server. The public server > can check and respond if the license is valid. There's no need for it > to send you a request later. I am not sure at this point David S. what you have tried, but I can assure you that your conclusion that "configuration is the only way in this scenario above" is incorrect, because I do this all the time with no difficulties whatsoever. It doesn't make sense to assume that the web service installed on the client inside some network will be reachable from the external network. If this is what you're doing, configuration (having the client app user set the URL) is the only way to set it up because they (the client) will likely need to open up some incoming requests that they normally would not allow through their firewalls anyway. The firewall issue is different. It is true that if you have the correct URL or IP address that a caller cannot get through if there is a firewall blocking the port. But that is a totally separate concern. It in fact does make sense to assume that a web service installed on a network will be reachable from an external network. There would otherwise be no sense at all to having the web service. If you toss in these firewall issues, you will only be muddying the waters with irrelevant concerns that are unrelated to this problem. I hope that did not sound too preachy. I guess I am just pretty sure in this area and hope that you all will see I am only trying to help. I am sure because I have gone through all the problems in one way or another related to this many times. Wasn't Martin the originator of this thread? Maybe you are talking about a sub-thread issue? Jack -- -- "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]
Re: PlugIn and the base URL
On Fri, 28 Jan 2005 08:02:46 -0600, David Suarez <[EMAIL PROTECTED]> wrote: > Just the same, it's > likely not a problem for your server to figure out where the request > came from if that is needed for the protocol (the receiver of the > initial message). It's the callback that you have a problem with and it > sounds like it's for a reason... It doesn't make sense to assume that > the web service installed on the client inside some network will be > reachable from the external network. If this is what you're doing, > configuration (having the client app user set the URL) is the only way > to set it up because they (the client) will likely need to open up some > incoming requests that they normally would not allow through their > firewalls anyway. Not to mention whatever you grab would be the > "internal" ip addresses. If your server grabs the ip from the request, > it is likely to a proxy somewhere and not to your app. This would seem to make sense, I guess, David S., but it does not. The ip address you want is the one that a foreign user should use to get to you and if you send a request, as I suggested, via a mini-browser in your PlugIn, the TCP/IP HTTP protocols will send to the recipient the IP address needed to reach your machine. Then, that machine can send back to you what that is. I know this works because I do it all the time. You can determine the same thing by sending the message to another machine on another port in the same intranet. Jack -- -- "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]
RE: PlugIn and the base URL
Hello, Looks like there's more than 1 David on this list. I'm the one who originally asked the question that you gave responses to. I guess all David's think alike and ask the same startup questions... ;-) Anyway, from the fogginess so far this is what I can conjure up as a make pretend example that may be something similar to what you're trying to do: You have a user application that you are distributing that is sending messages to a known server for some reason. Let's make pretend it's for licensing checks. That's all good and fair and there's no issue with your application sending the soap request to your known server. Just the same, it's likely not a problem for your server to figure out where the request came from if that is needed for the protocol (the receiver of the initial message). It's the callback that you have a problem with and it sounds like it's for a reason... It doesn't make sense to assume that the web service installed on the client inside some network will be reachable from the external network. If this is what you're doing, configuration (having the client app user set the URL) is the only way to set it up because they (the client) will likely need to open up some incoming requests that they normally would not allow through their firewalls anyway. Not to mention whatever you grab would be the "internal" ip addresses. If your server grabs the ip from the request, it is likely to a proxy somewhere and not to your app. I think the answer here would be configuration is the only way in the scenario above. The question is, do you really need the call backs for what you're really doing? In the licensing example above, you likely only need to send the request to the public server. The public server can check and respond if the license is valid. There's no need for it to send you a request later. Again, just some thoughts to help you think through what you're doing, hopefully it helps you figure out the right course of action. Regards...djsuaerz -Original Message- From: Martin Wegner [mailto:[EMAIL PROTECTED] Sent: Thursday, January 27, 2005 11:17 PM To: Struts Users Mailing List Subject: RE: PlugIn and the base URL David, Also, as I said early the Axis architecture is such that it does not provide any of the information related to the HTTP layer beneath SOAP. The only think you know is that your dispatcher gets called. So my problem may be considered a limitation in Axis. --Marty > Martin, since you seem firm on this issue, can we/I ask WHY you need > this > information in your webapp during initialization? What are you doing > that > you cannot set that information per request (HTTP/SOAP) in your output? > (Or > use relative URLS of some sort) Knowing WHY, perhaps someone on the list > can > suggest an alternate, yet equally effective, solution for the issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PlugIn and the base URL
On Thu, 27 Jan 2005 22:46:20 -0800 (PST), Martin Wegner <[EMAIL PROTECTED]> wrote: > Jack, > > Your solution would work. But I don't have the ability to deploy a > foreign machine to do the echo. > > Someone just wrote in about a Struts filter on "/axis/" which may actually > do the trick. I need to look into that one. No matter what, I think you have to either configure the machine by people, wait to be contacted (and I have to wonder how you will be contacted) or you have to go outside to get the information. This is just part of the way tcp/ip http works. The cost would be miniscule. You only need to handle application startups. You could do it for all clients for about 10 bucks a month. I cannot believe that your product would not be worth that. You could even have an ongoing cost if you liked with your clients so that they supported it or have them do the foreign host and give them the stuff. -- -- "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]
Re: PlugIn and the base URL
Martin, Please note that in the message classes in cos there is an input stream returned with which you read the response. The host computer which your client's plugin calls sends a response which has all the information needed and the PlugIn reads the response. I have the "host computer" use some multithreaded queques using Doug Lea's concurrency stuff (http://gee.cs.oswego.edu/dl/) to handle these messages. Notice that the message is a simple http request with a response (input stream). Jack On Thu, 27 Jan 2005 22:34:37 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > -- Forwarded message -- > From: Dakota Jack <[EMAIL PROTECTED]> > Date: Thu, 27 Jan 2005 22:24:00 -0800 > Subject: Re: PlugIn and the base URL > > To: Martin Wegner <[EMAIL PROTECTED]> > > > On Thu, 27 Jan 2005 21:25:11 -0800 (PST), Martin Wegner > <[EMAIL PROTECTED]> wrote: > > Jack, > > > > How do you have the PlugIn call into the Struts app? How do you craft the > > URL? > > > As you know, the URL has to be converted into an IP address anyway. > So, since people are out of the loop, we will just start with one. > > First, have the PlugIn call a "foreign" or "outside" machine with a > request of its own. This can be done, for example, with something > like the messaging classes with Jason Hunter's cos jar at > http://servlets.com/cos/ and check out HttpMessage and HttpsMessage to > get an idea of what you can do. Send the foreign machne a message > with the needed information such as the port number, and whatever. > When the foreign machine gets your message, have it extract your IP > address and message it back to you via message by adding the port and > other information as needed. This will be returned to the PlugIn. > Getting this return message, you now have everything you need for the > SOAP protocol in URL terms, i.e. "http://[ip address from the foriegn > host]/port/whatever". Set the information and you are set to go. > Understand? You are actually just writing a little Java browser for > you own purposes inside the PlugIn. > > Jack > > -- > -- > > "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." > > -- > -- > > "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." > -- -- "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]
Fwd: PlugIn and the base URL
-- Forwarded message -- From: Dakota Jack <[EMAIL PROTECTED]> Date: Thu, 27 Jan 2005 22:24:00 -0800 Subject: Re: PlugIn and the base URL To: Martin Wegner <[EMAIL PROTECTED]> On Thu, 27 Jan 2005 21:25:11 -0800 (PST), Martin Wegner <[EMAIL PROTECTED]> wrote: > Jack, > > How do you have the PlugIn call into the Struts app? How do you craft the > URL? As you know, the URL has to be converted into an IP address anyway. So, since people are out of the loop, we will just start with one. First, have the PlugIn call a "foreign" or "outside" machine with a request of its own. This can be done, for example, with something like the messaging classes with Jason Hunter's cos jar at http://servlets.com/cos/ and check out HttpMessage and HttpsMessage to get an idea of what you can do. Send the foreign machne a message with the needed information such as the port number, and whatever. When the foreign machine gets your message, have it extract your IP address and message it back to you via message by adding the port and other information as needed. This will be returned to the PlugIn. Getting this return message, you now have everything you need for the SOAP protocol in URL terms, i.e. "http://[ip address from the foriegn host]/port/whatever". Set the information and you are set to go. Understand? You are actually just writing a little Java browser for you own purposes inside the PlugIn. Jack -- -- "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." -- -- "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]
Re: PlugIn and the base URL
On Thu, 27 Jan 2005 21:17:07 -0800 (PST), Martin Wegner <[EMAIL PROTECTED]> wrote: > David, > > Also, as I said early the Axis architecture is such that it does not > provide any of the information related to the HTTP layer beneath SOAP. > The only think you know is that your dispatcher gets called. So my > problem may be considered a limitation in Axis. > Assuming that all your web service requests to Axis contains /axis in the path for eg(http://company.com/axis/WebService.jws), I guess you could have a Filter for the url-pattern /axis/* whose job is to take the path that was requested (eg http://company.com/axis/WebService.jws) and stick it into your business objects? Essentially having a Filter instead of a Plugin. So, when a web service is requested, before the request reaches the AxisServlet, the Filter would save the URL in the business objects and your business objects can throw that URL into the response. Wouldn't this work? > --Marty > > > Martin, since you seem firm on this issue, can we/I ask WHY you need > > this > > information in your webapp during initialization? What are you doing > > that > > you cannot set that information per request (HTTP/SOAP) in your output? > > (Or > > use relative URLS of some sort) Knowing WHY, perhaps someone on the list > > can > > suggest an alternate, yet equally effective, solution for the issue. > > > - > 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]
RE: PlugIn and the base URL
David, Also, as I said early the Axis architecture is such that it does not provide any of the information related to the HTTP layer beneath SOAP. The only think you know is that your dispatcher gets called. So my problem may be considered a limitation in Axis. --Marty > Martin, since you seem firm on this issue, can we/I ask WHY you need > this > information in your webapp during initialization? What are you doing > that > you cannot set that information per request (HTTP/SOAP) in your output? > (Or > use relative URLS of some sort) Knowing WHY, perhaps someone on the list > can > suggest an alternate, yet equally effective, solution for the issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PlugIn and the base URL
David, As I said in a previous message my Struts app has an Axis-based SOAP service. The business logic behind the WS needs to know a/the URL that can be used to access the WS. This is a requirement of the WS. This part can't be changed. It is part of the protocol of the answer sent back by the WS. So the question becomes: if the web container, port number, IP address(es) and WAR file name can all cahnge, how does the Struts PlugIn figure out a/the URL to access the WS? As stated earlier, if a human were to log in then the Request object would contain all of the necessary info. But the PlugIn does not have a Request object. So the question becomes: what is the trick to get the PlugIn to generate a Request object? Clearly you could use something like HttpClient to make an HTTP call back to the main app, but how do you construct the URL at run time? You can't contact yourself unless you make at least a few assumptions. And I can't make those in this case. The other good answer was to force the user to supply the URL via an external file or via an installer. That is the solution I have adopted for the time being. --Marty --- "David G. Friedman" <[EMAIL PROTECTED]> wrote: > >>Martin Wegner wrote: > >>In have a Struts PlugIn that needs to determine the > >> URL for the containing web application > >> (http://localhost:8080/BlahBlahBlah/). > > Martin, since you seem firm on this issue, can we/I ask WHY you need > this > information in your webapp during initialization? What are you doing > that > you cannot set that information per request (HTTP/SOAP) in your output? > (Or > use relative URLS of some sort) Knowing WHY, perhaps someone on the list > can > suggest an alternate, yet equally effective, solution for the issue. > > Regards, > David > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PlugIn and the base URL
I think it is important to remember that the URL is a "detail" that is wholly independent of the application or the machine. This is an external device for the benefit of human beings whom do not do as well with numbers as with letters in the memonic department. Therefore, I don't think that this is a problem within AXIS? Right? Jack On Wed, 26 Jan 2005 09:53:26 -0800 (PST), Martin Wegner <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > > __ > > This e-mail and the documents attached are confidential and intended > > solely for the addressee; it may also be privileged. If you receive this > > > > e-mail in error, please notify the sender immediately and destroy it. > > As its integrity cannot be secured on the Internet, the Atos Origin > > group > > liability cannot be triggered for the message content. Although the > > sender endeavours to maintain a computer virus-free network, the sender > > does not warrant that this transmission is virus-free and will not be > > liable for any damages resulting from any virus transmitted. > > > __ > > > > - > > 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]
Re: PlugIn and the base URL
David, I do not mean to speak for Martin, but my guess is that he might want to send SOAP prior to a request. He might even have to send and to receive SOAP prior to a request.I know that this is why I often need to do this sort of thing. Jack On Thu, 27 Jan 2005 18:50:08 -0500, David G. Friedman <[EMAIL PROTECTED]> wrote: > >>Martin Wegner wrote: > >>In have a Struts PlugIn that needs to determine the > >> URL for the containing web application > >> (http://localhost:8080/BlahBlahBlah/). > > Martin, since you seem firm on this issue, can we/I ask WHY you need this > information in your webapp during initialization? What are you doing that > you cannot set that information per request (HTTP/SOAP) in your output? (Or > use relative URLS of some sort) Knowing WHY, perhaps someone on the list can > suggest an alternate, yet equally effective, solution for the issue. > > Regards, > David > > - > 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]
RE: PlugIn and the base URL
>>Martin Wegner wrote: >>In have a Struts PlugIn that needs to determine the >> URL for the containing web application >> (http://localhost:8080/BlahBlahBlah/). Martin, since you seem firm on this issue, can we/I ask WHY you need this information in your webapp during initialization? What are you doing that you cannot set that information per request (HTTP/SOAP) in your output? (Or use relative URLS of some sort) Knowing WHY, perhaps someone on the list can suggest an alternate, yet equally effective, solution for the issue. Regards, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PlugIn and the base URL
You cannot count on this. You need to go outside to an external machine and ask it who you are. You might, for example, be on an intranet and only have a local address from your machines point of view. Jack On Thu, 27 Jan 2005 08:11:54 -0600, David Suarez <[EMAIL PROTECTED]> wrote: > The light came on when "the ip address is sufficient" came up. I had > context paths and ports in my head. If that's all you need, look at the > "INetAddress" classes which have methods to get a host name and ip > address for the "localhost". > > Regards...djsuarez > > -Original Message- > From: Martin Wegner [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 26, 2005 11:51 PM > To: Struts Users Mailing List; Dakota Jack > Subject: Re: PlugIn and the base URL > > > Thanks to everybody who contributed to this topic. There appears to be > no > foolproof solution to the particular problem that I have. I think I > will > have to go with an external installer/config program. > > Thanks again to everybody. > > --Marty > > --- Dakota Jack <[EMAIL PROTECTED]> wrote: > > > Anyway, if an IP address is sufficient, and why wouldn't it be (?), > > then all you have to do is to provide a servlet to tell all machines > > that ask their IP address. That is simple. No? > > > > Jack > > > > > > On Wed, 26 Jan 2005 16:09:13 -0800, Dakota Jack > <[EMAIL PROTECTED]> > > wrote: > > > Since this is SOAP and a dynamic feature, wouldn't and IP address > work > > > as well, or better? > > > > > > Jack > > > > > > On Wed, 26 Jan 2005 07:12:03 -0800 (PST), Martin Wegner > > > <[EMAIL PROTECTED]> wrote: > > > > David, > > > > > > > > My Struts app contains an Axis-based SOAP service. The Struts app > > > > initializes the call dispatcher for the SOAP service. This > > dispatcher > > > > needs to know the URL of itself. This is a requirement of the > > semantics > > > > of the SOAP service (outside of my control). So a Listener or a > > Plug In > > > > appear to be the only way to try to determine the URL before the > > SOAP > > > > service is open for business. > > > > > > > > Thanks. > > > > > > > > --Marty > > > > > > > > --- David Suarez <[EMAIL PROTECTED]> wrote: > > > > > > > > > Is your plug-in a 3rd party type component? What is the purpose > > of > > > > > obtaining the URL? Maybe there's a suitable alternative > depending > > on > > > > > your requirements (ie. A Filter that would instantiate the > objects > > you > > > > > need to populate on the first request? A base action that lazy > > loads > > > > > your config stuff?) > > > > > > > > > > Just a thought...djsuarez > > > > > > > > > > -Original Message- > > > > > From: Martin Wegner [mailto:[EMAIL PROTECTED] > > > > > Sent: Wednesday, January 26, 2005 12:18 AM > > > > > To: Struts Users Mailing List; Dakota Jack > > > > > Subject: Re: PlugIn and the base URL > > > > > > > > > > > > > > > > I am looking for the: > > > > > > > > > > http://blahblahblah.com:8080/AppName/ > > > > > > > > > > As Craig said I can get that if I have a Request object. But > from > > a > > > > > PlugIn I don't have that. I can think of some ugly hacks but > > nothing > > > > > clean. > > > > > > > > > > > > > > > --Marty > > > > > > > > > > --- Dakota Jack <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > Do you want the URL or the Internet Protocol address? I have > > some > > > > > > ideas on the latter. > > > > > > > > > > > > Jack > > > > > > > > > > > > > > > > > > On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner > > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > Jack, > > > > > > > > > > > > > > That tells me where the JAR files are stored which is cool. > > But > > > > > what > > > > > > I am > > > > > > > looking for a valid UR
RE: PlugIn and the base URL
Forgot to add the disclaimers..: 1) Craig's point is correct. Something like the below kind of defeats any load balancing type setup that may exist on a more generic host name 2) In my mind, web services are great for the cross-platform/external service. But if the only one that knows the location of the where the web service is the webapp, why not call the logic directly instead of via a web service? Again, I'm probably not understanding what you're doing but I hope the thoughts above help you to decide the best thing for you. Regards...djsuarez -Original Message- From: David Suarez Sent: Thursday, January 27, 2005 8:12 AM To: 'Martin Wegner'; Struts Users Mailing List; Dakota Jack Subject: RE: PlugIn and the base URL The light came on when "the ip address is sufficient" came up. I had context paths and ports in my head. If that's all you need, look at the "INetAddress" classes which have methods to get a host name and ip address for the "localhost". Regards...djsuarez -Original Message- From: Martin Wegner [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 26, 2005 11:51 PM To: Struts Users Mailing List; Dakota Jack Subject: Re: PlugIn and the base URL Thanks to everybody who contributed to this topic. There appears to be no foolproof solution to the particular problem that I have. I think I will have to go with an external installer/config program. Thanks again to everybody. --Marty --- Dakota Jack <[EMAIL PROTECTED]> wrote: > Anyway, if an IP address is sufficient, and why wouldn't it be (?), > then all you have to do is to provide a servlet to tell all machines > that ask their IP address. That is simple. No? > > Jack > > > On Wed, 26 Jan 2005 16:09:13 -0800, Dakota Jack <[EMAIL PROTECTED]> > wrote: > > Since this is SOAP and a dynamic feature, wouldn't and IP address work > > as well, or better? > > > > Jack > > > > On Wed, 26 Jan 2005 07:12:03 -0800 (PST), Martin Wegner > > <[EMAIL PROTECTED]> wrote: > > > David, > > > > > > My Struts app contains an Axis-based SOAP service. The Struts app > > > initializes the call dispatcher for the SOAP service. This > dispatcher > > > needs to know the URL of itself. This is a requirement of the > semantics > > > of the SOAP service (outside of my control). So a Listener or a > Plug In > > > appear to be the only way to try to determine the URL before the > SOAP > > > service is open for business. > > > > > > Thanks. > > > > > > --Marty > > > > > > --- David Suarez <[EMAIL PROTECTED]> wrote: > > > > > > > Is your plug-in a 3rd party type component? What is the purpose > of > > > > obtaining the URL? Maybe there's a suitable alternative depending > on > > > > your requirements (ie. A Filter that would instantiate the objects > you > > > > need to populate on the first request? A base action that lazy > loads > > > > your config stuff?) > > > > > > > > Just a thought...djsuarez > > > > > > > > -Original Message- > > > > From: Martin Wegner [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday, January 26, 2005 12:18 AM > > > > To: Struts Users Mailing List; Dakota Jack > > > > Subject: Re: PlugIn and the base URL > > > > > > > > > > > > I am looking for the: > > > > > > > > http://blahblahblah.com:8080/AppName/ > > > > > > > > As Craig said I can get that if I have a Request object. But from > a > > > > PlugIn I don't have that. I can think of some ugly hacks but > nothing > > > > clean. > > > > > > > > > > > > --Marty > > > > > > > > --- Dakota Jack <[EMAIL PROTECTED]> wrote: > > > > > > > > > Do you want the URL or the Internet Protocol address? I have > some > > > > > ideas on the latter. > > > > > > > > > > Jack > > > > > > > > > > > > > > > On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > Jack, > > > > > > > > > > > > That tells me where the JAR files are stored which is cool. > But > > > > what > > > > > I am > > > > > > looking for a valid URL (of which there may be many) to access > my > > > > > given > > > >
RE: PlugIn and the base URL
The light came on when "the ip address is sufficient" came up. I had context paths and ports in my head. If that's all you need, look at the "INetAddress" classes which have methods to get a host name and ip address for the "localhost". Regards...djsuarez -Original Message- From: Martin Wegner [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 26, 2005 11:51 PM To: Struts Users Mailing List; Dakota Jack Subject: Re: PlugIn and the base URL Thanks to everybody who contributed to this topic. There appears to be no foolproof solution to the particular problem that I have. I think I will have to go with an external installer/config program. Thanks again to everybody. --Marty --- Dakota Jack <[EMAIL PROTECTED]> wrote: > Anyway, if an IP address is sufficient, and why wouldn't it be (?), > then all you have to do is to provide a servlet to tell all machines > that ask their IP address. That is simple. No? > > Jack > > > On Wed, 26 Jan 2005 16:09:13 -0800, Dakota Jack <[EMAIL PROTECTED]> > wrote: > > Since this is SOAP and a dynamic feature, wouldn't and IP address work > > as well, or better? > > > > Jack > > > > On Wed, 26 Jan 2005 07:12:03 -0800 (PST), Martin Wegner > > <[EMAIL PROTECTED]> wrote: > > > David, > > > > > > My Struts app contains an Axis-based SOAP service. The Struts app > > > initializes the call dispatcher for the SOAP service. This > dispatcher > > > needs to know the URL of itself. This is a requirement of the > semantics > > > of the SOAP service (outside of my control). So a Listener or a > Plug In > > > appear to be the only way to try to determine the URL before the > SOAP > > > service is open for business. > > > > > > Thanks. > > > > > > --Marty > > > > > > --- David Suarez <[EMAIL PROTECTED]> wrote: > > > > > > > Is your plug-in a 3rd party type component? What is the purpose > of > > > > obtaining the URL? Maybe there's a suitable alternative depending > on > > > > your requirements (ie. A Filter that would instantiate the objects > you > > > > need to populate on the first request? A base action that lazy > loads > > > > your config stuff?) > > > > > > > > Just a thought...djsuarez > > > > > > > > -Original Message- > > > > From: Martin Wegner [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday, January 26, 2005 12:18 AM > > > > To: Struts Users Mailing List; Dakota Jack > > > > Subject: Re: PlugIn and the base URL > > > > > > > > > > > > I am looking for the: > > > > > > > > http://blahblahblah.com:8080/AppName/ > > > > > > > > As Craig said I can get that if I have a Request object. But from > a > > > > PlugIn I don't have that. I can think of some ugly hacks but > nothing > > > > clean. > > > > > > > > > > > > --Marty > > > > > > > > --- Dakota Jack <[EMAIL PROTECTED]> wrote: > > > > > > > > > Do you want the URL or the Internet Protocol address? I have > some > > > > > ideas on the latter. > > > > > > > > > > Jack > > > > > > > > > > > > > > > On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > Jack, > > > > > > > > > > > > That tells me where the JAR files are stored which is cool. > But > > > > what > > > > > I am > > > > > > looking for a valid URL (of which there may be many) to access > my > > > > > given > > > > > > web application. This info has to come from the container > which may > > > > > be > > > > > > the problem. I don't see anything in the container standard > which > > > > > > provides this info. > > > > > > > > > > > > Any other ideas? > > > > > > > > > > > > --Marty > > > > > > > > > > > > --- Dakota Jack <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > Not sure what you want. Does this help? > > > > > > > > > > > > > > package whatever; > > > > > > > > > > >
RE: PlugIn and the base URL
Craig, I knew I should have put that tidbit in my email - it was in my first revision. I took it out because it sounded too preachy in my first draft. I agree with you since the product I'm working on has every virtualhost mapped to one Tomcat context for application sharing. As we've read, Martin seems to be assuming the opposite (exactly one context for his customer) and has his mind 100% stuck on MAGIC setup the very first time. Personally, I do not see anything wrong with waiting for the first SOAP or HTTP call to perform the setup steps. Even if that first call takes 20-30 seconds (read: outch!), further calls will be instant. If you save that URL somewhere (file, DB, etc.), the plugIn can "know" that information and upon further webapp restarts perform initialization instantly so no further wait occurs. If Martin is 100% sure of his future clients' setup(s), my suggestion could work. Heck, he could even make those conditions a requirement for deployment: port 80 and a specific context on both the web server and java app server. That doesn't seem like much of an issue for "selling" something. Regards, David -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, January 27, 2005 1:06 AM To: Struts Users Mailing List Subject: Re: PlugIn and the base URL On Wed, 26 Jan 2005 13:32:50 -0500, David G. Friedman <[EMAIL PROTECTED]> wrote: > 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. The assumption that a particular webapp only has one context path -- or even one host:port combination -- is not in conformance with reality on most modern servers. Consider, for example, how many environments are set up such that "www.mycompany.com" and "company.com" resolve to the same webapp. The same sort of aliasing of the context path is trivially simple in any modern web server or app server. Application architectures based on the assumption that there is one-and-only-one URL for the app should be rethought. Craig - 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]
Re: PlugIn and the base URL
On Wed, 26 Jan 2005 13:32:50 -0500, David G. Friedman <[EMAIL PROTECTED]> wrote: > 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. The assumption that a particular webapp only has one context path -- or even one host:port combination -- is not in conformance with reality on most modern servers. Consider, for example, how many environments are set up such that "www.mycompany.com" and "company.com" resolve to the same webapp. The same sort of aliasing of the context path is trivially simple in any modern web server or app server. Application architectures based on the assumption that there is one-and-only-one URL for the app should be rethought. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PlugIn and the base URL
Thanks to everybody who contributed to this topic. There appears to be no
foolproof solution to the particular problem that I have. I think I will
have to go with an external installer/config program.
Thanks again to everybody.
--Marty
--- Dakota Jack <[EMAIL PROTECTED]> wrote:
> Anyway, if an IP address is sufficient, and why wouldn't it be (?),
> then all you have to do is to provide a servlet to tell all machines
> that ask their IP address. That is simple. No?
>
> Jack
>
>
> On Wed, 26 Jan 2005 16:09:13 -0800, Dakota Jack <[EMAIL PROTECTED]>
> wrote:
> > Since this is SOAP and a dynamic feature, wouldn't and IP address work
> > as well, or better?
> >
> > Jack
> >
> > On Wed, 26 Jan 2005 07:12:03 -0800 (PST), Martin Wegner
> > <[EMAIL PROTECTED]> wrote:
> > > David,
> > >
> > > My Struts app contains an Axis-based SOAP service. The Struts app
> > > initializes the call dispatcher for the SOAP service. This
> dispatcher
> > > needs to know the URL of itself. This is a requirement of the
> semantics
> > > of the SOAP service (outside of my control). So a Listener or a
> Plug In
> > > appear to be the only way to try to determine the URL before the
> SOAP
> > > service is open for business.
> > >
> > > Thanks.
> > >
> > > --Marty
> > >
> > > --- David Suarez <[EMAIL PROTECTED]> wrote:
> > >
> > > > Is your plug-in a 3rd party type component? What is the purpose
> of
> > > > obtaining the URL? Maybe there's a suitable alternative depending
> on
> > > > your requirements (ie. A Filter that would instantiate the objects
> you
> > > > need to populate on the first request? A base action that lazy
> loads
> > > > your config stuff?)
> > > >
> > > > Just a thought...djsuarez
> > > >
> > > > -Original Message-
> > > > From: Martin Wegner [mailto:[EMAIL PROTECTED]
> > > > Sent: Wednesday, January 26, 2005 12:18 AM
> > > > To: Struts Users Mailing List; Dakota Jack
> > > > Subject: Re: PlugIn and the base URL
> > > >
> > > >
> > > > I am looking for the:
> > > >
> > > > http://blahblahblah.com:8080/AppName/
> > > >
> > > > As Craig said I can get that if I have a Request object. But from
> a
> > > > PlugIn I don't have that. I can think of some ugly hacks but
> nothing
> > > > clean.
> > > >
> > > >
> > > > --Marty
> > > >
> > > > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Do you want the URL or the Internet Protocol address? I have
> some
> > > > > ideas on the latter.
> > > > >
> > > > > Jack
> > > > >
> > > > >
> > > > > On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner
> > > > > <[EMAIL PROTECTED]> wrote:
> > > > > > Jack,
> > > > > >
> > > > > > That tells me where the JAR files are stored which is cool.
> But
> > > > what
> > > > > I am
> > > > > > looking for a valid URL (of which there may be many) to access
> my
> > > > > given
> > > > > > web application. This info has to come from the container
> which may
> > > > > be
> > > > > > the problem. I don't see anything in the container standard
> which
> > > > > > provides this info.
> > > > > >
> > > > > > Any other ideas?
> > > > > >
> > > > > > --Marty
> > > > > >
> > > > > > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > > Not sure what you want. Does this help?
> > > > > > >
> > > > > > > package whatever;
> > > > > > >
> > > > > > > import java.io.File;
> > > > > > > import java.net.URL;
> > > > > > >
> > > > > > > public final class Classpath {
> > > > > > > public static final String SLASH= File.separator;
> > > > > > > public static final String HERE =
> > > > > > > Classpath.class.getClassLoader().getResource("whatever" +
> SLASH +
> &
Re: PlugIn and the base URL
Anyway, if an IP address is sufficient, and why wouldn't it be (?),
then all you have to do is to provide a servlet to tell all machines
that ask their IP address. That is simple. No?
Jack
On Wed, 26 Jan 2005 16:09:13 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote:
> Since this is SOAP and a dynamic feature, wouldn't and IP address work
> as well, or better?
>
> Jack
>
> On Wed, 26 Jan 2005 07:12:03 -0800 (PST), Martin Wegner
> <[EMAIL PROTECTED]> wrote:
> > David,
> >
> > My Struts app contains an Axis-based SOAP service. The Struts app
> > initializes the call dispatcher for the SOAP service. This dispatcher
> > needs to know the URL of itself. This is a requirement of the semantics
> > of the SOAP service (outside of my control). So a Listener or a Plug In
> > appear to be the only way to try to determine the URL before the SOAP
> > service is open for business.
> >
> > Thanks.
> >
> > --Marty
> >
> > --- David Suarez <[EMAIL PROTECTED]> wrote:
> >
> > > Is your plug-in a 3rd party type component? What is the purpose of
> > > obtaining the URL? Maybe there's a suitable alternative depending on
> > > your requirements (ie. A Filter that would instantiate the objects you
> > > need to populate on the first request? A base action that lazy loads
> > > your config stuff?)
> > >
> > > Just a thought...djsuarez
> > >
> > > -Original Message-
> > > From: Martin Wegner [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, January 26, 2005 12:18 AM
> > > To: Struts Users Mailing List; Dakota Jack
> > > Subject: Re: PlugIn and the base URL
> > >
> > >
> > > I am looking for the:
> > >
> > > http://blahblahblah.com:8080/AppName/
> > >
> > > As Craig said I can get that if I have a Request object. But from a
> > > PlugIn I don't have that. I can think of some ugly hacks but nothing
> > > clean.
> > >
> > >
> > > --Marty
> > >
> > > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> > >
> > > > Do you want the URL or the Internet Protocol address? I have some
> > > > ideas on the latter.
> > > >
> > > > Jack
> > > >
> > > >
> > > > On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner
> > > > <[EMAIL PROTECTED]> wrote:
> > > > > Jack,
> > > > >
> > > > > That tells me where the JAR files are stored which is cool. But
> > > what
> > > > I am
> > > > > looking for a valid URL (of which there may be many) to access my
> > > > given
> > > > > web application. This info has to come from the container which may
> > > > be
> > > > > the problem. I don't see anything in the container standard which
> > > > > provides this info.
> > > > >
> > > > > Any other ideas?
> > > > >
> > > > > --Marty
> > > > >
> > > > > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > > Not sure what you want. Does this help?
> > > > > >
> > > > > > package whatever;
> > > > > >
> > > > > > import java.io.File;
> > > > > > import java.net.URL;
> > > > > >
> > > > > > public final class Classpath {
> > > > > > public static final String SLASH= File.separator;
> > > > > > public static final String HERE =
> > > > > > Classpath.class.getClassLoader().getResource("whatever" + SLASH +
> > > > > >
> > > > > > "Classpath.class").getFile();
> > > > > > }
> > > > > >
> > > > > >
> > > > > > On Tue, 25 Jan 2005 19:25:21 -0800 (PST), Martin Wegner
> > > > > > <[EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > As far as I can tell the attributes offer no insight. I have
> > > yet
> > > > to
> > > > > > find
> > > > > > > a way to get to the container from within a PlugIn. But I will
> > > > keep
> > > > > > > looking. Using an initParam is not an option in this
> > > application.
> > > > > > >
> > > > > > > --M
Re: PlugIn and the base URL
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
Re: PlugIn and the base URL
Even if you did need to know it, why not get it at the first request and then cache it? Jack On Wed, 26 Jan 2005 16:59:17 +0100, Cedric Levieux <[EMAIL PROTECTED]> wrote: > > My Struts app contains an Axis-based SOAP service. The Struts app > > initializes the call dispatcher for the SOAP service. This dispatcher > > needs to know the URL of itself. This is a requirement of the semantics > > of the SOAP service (outside of my control). So a Listener or a Plug In > > appear to be the only way to try to determine the URL before the SOAP > > service is open for business. > > I don't understand this point in fact, cause in ones of my working struts > applications there are some > axis-soap web services and I didn't need to give my url path to axis-soap. > > So i'm very confuse in fact .. > > Cedric > > > - > 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]
Re: PlugIn and the base URL
Heck, I think this is one cut above a hack? ;-) Jack On Wed, 26 Jan 2005 07:21:52 -0800 (PST), Martin Wegner <[EMAIL PROTECTED]> wrote: > Frank, > > Yeah, that was the one hack that came to mind yesterday. It would > definitely work. If there is no alternative that is what I will have to > do. But I am hoping that the Struts gurus have a better answer in their > pocket. > > Thanks. > > --Marty > > --- [EMAIL PROTECTED] wrote: > > > Just thinking out loud here, but... > > > > What if from your plug-in you spawn a thread that will: > > > > (1) Wait a few second, to allow the app to otherwise initialize > > completely > > (2) Make a request to a special Action that will do the rest of the > > initialization that requires the URL (should be able to do > > http://localhost/myapp) > > (3) Die > > > > I do something similar for database initialization... I spaw a thread > > from the plug-in, wait a few seconds, then make a call to my database > > connection manager class, which has the effect of creating the > > connection pool. This way I know it's done before the first request > > comes in. Similar kind of idea. > > > > -- > > Frank W. Zammetti > > Founder and Chief Software Architect > > Omnytex Technologies > > http://www.omnytex.com > > > > On Wed, January 26, 2005 10:12 am, Martin Wegner said: > > > David, > > > > > > My Struts app contains an Axis-based SOAP service. The Struts app > > > initializes the call dispatcher for the SOAP service. This dispatcher > > > needs to know the URL of itself. This is a requirement of the > > semantics > > > of the SOAP service (outside of my control). So a Listener or a Plug > > In > > > appear to be the only way to try to determine the URL before the SOAP > > > service is open for business. > > > > > > Thanks. > > > > > > > > > --Marty > > > > > > --- David Suarez <[EMAIL PROTECTED]> wrote: > > > > > >> Is your plug-in a 3rd party type component? What is the purpose of > > >> obtaining the URL? Maybe there's a suitable alternative depending on > > >> your requirements (ie. A Filter that would instantiate the objects > > you > > >> need to populate on the first request? A base action that lazy loads > > >> your config stuff?) > > >> > > >> Just a thought...djsuarez > > >> > > >> -Original Message- > > >> From: Martin Wegner [mailto:[EMAIL PROTECTED] > > >> Sent: Wednesday, January 26, 2005 12:18 AM > > >> To: Struts Users Mailing List; Dakota Jack > > >> Subject: Re: PlugIn and the base URL > > >> > > >> > > >> I am looking for the: > > >> > > >> http://blahblahblah.com:8080/AppName/ > > >> > > >> As Craig said I can get that if I have a Request object. But from a > > >> PlugIn I don't have that. I can think of some ugly hacks but nothing > > >> clean. > > >> > > >> > > >> --Marty > > >> > > >> --- Dakota Jack <[EMAIL PROTECTED]> wrote: > > >> > > >> > Do you want the URL or the Internet Protocol address? I have some > > >> > ideas on the latter. > > >> > > > >> > Jack > > >> > > > >> > > > >> > On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner > > >> > <[EMAIL PROTECTED]> wrote: > > >> > > Jack, > > >> > > > > >> > > That tells me where the JAR files are stored which is cool. But > > >> what > > >> > I am > > >> > > looking for a valid URL (of which there may be many) to access my > > >> > given > > >> > > web application. This info has to come from the container which > > may > > >> > be > > >> > > the problem. I don't see anything in the container standard > > which > > >> > > provides this info. > > >> > > > > >> > > Any other ideas? > > >> > > > > >> > > --Marty > > >> > > > > >> > > --- Dakota Jack <[EMAIL PROTECTED]> wrote: > > >> > > > > >> > > > Not sure what you want. Does this help? > > >> > > > > > >> > &g
Re: PlugIn and the base URL
Since this is SOAP and a dynamic feature, wouldn't and IP address work
as well, or better?
Jack
On Wed, 26 Jan 2005 07:12:03 -0800 (PST), Martin Wegner
<[EMAIL PROTECTED]> wrote:
> David,
>
> My Struts app contains an Axis-based SOAP service. The Struts app
> initializes the call dispatcher for the SOAP service. This dispatcher
> needs to know the URL of itself. This is a requirement of the semantics
> of the SOAP service (outside of my control). So a Listener or a Plug In
> appear to be the only way to try to determine the URL before the SOAP
> service is open for business.
>
> Thanks.
>
> --Marty
>
> --- David Suarez <[EMAIL PROTECTED]> wrote:
>
> > Is your plug-in a 3rd party type component? What is the purpose of
> > obtaining the URL? Maybe there's a suitable alternative depending on
> > your requirements (ie. A Filter that would instantiate the objects you
> > need to populate on the first request? A base action that lazy loads
> > your config stuff?)
> >
> > Just a thought...djsuarez
> >
> > -Original Message-
> > From: Martin Wegner [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, January 26, 2005 12:18 AM
> > To: Struts Users Mailing List; Dakota Jack
> > Subject: Re: PlugIn and the base URL
> >
> >
> > I am looking for the:
> >
> > http://blahblahblah.com:8080/AppName/
> >
> > As Craig said I can get that if I have a Request object. But from a
> > PlugIn I don't have that. I can think of some ugly hacks but nothing
> > clean.
> >
> >
> > --Marty
> >
> > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> >
> > > Do you want the URL or the Internet Protocol address? I have some
> > > ideas on the latter.
> > >
> > > Jack
> > >
> > >
> > > On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner
> > > <[EMAIL PROTECTED]> wrote:
> > > > Jack,
> > > >
> > > > That tells me where the JAR files are stored which is cool. But
> > what
> > > I am
> > > > looking for a valid URL (of which there may be many) to access my
> > > given
> > > > web application. This info has to come from the container which may
> > > be
> > > > the problem. I don't see anything in the container standard which
> > > > provides this info.
> > > >
> > > > Any other ideas?
> > > >
> > > > --Marty
> > > >
> > > > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Not sure what you want. Does this help?
> > > > >
> > > > > package whatever;
> > > > >
> > > > > import java.io.File;
> > > > > import java.net.URL;
> > > > >
> > > > > public final class Classpath {
> > > > > public static final String SLASH= File.separator;
> > > > > public static final String HERE =
> > > > > Classpath.class.getClassLoader().getResource("whatever" + SLASH +
> > > > >
> > > > > "Classpath.class").getFile();
> > > > > }
> > > > >
> > > > >
> > > > > On Tue, 25 Jan 2005 19:25:21 -0800 (PST), Martin Wegner
> > > > > <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > As far as I can tell the attributes offer no insight. I have
> > yet
> > > to
> > > > > find
> > > > > > a way to get to the container from within a PlugIn. But I will
> > > keep
> > > > > > looking. Using an initParam is not an option in this
> > application.
> > > > > >
> > > > > > --Marty
> > > > > >
> > > > > > --- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > > The OP was looking for a way to construct the entire path. I
> > > too
> > > > > got as
> > > > > > >
> > > > > > > far as ServletContext, but I'm not sure what in it would give
> > > you
> > > > > that,
> > > > > > > or even all the pieces to constuct it... Maybe getAttribute()?
> >
> > > I'm
> > > > > not
> > > > > > > sure what it will return, although you can use
> > > getAttributeNames()
> > > > >
RE: PlugIn and the base URL
Marty,
If you want to make major assumptions such as a) the client will always use
port 80 AND b) the client will always use the same /whatever context name
even when mapping through a web server to your Java application server, then
this line in your plugIn.init() will solve your problems:
url = arg0.getServletContext().getResource("/");
I tried it using my default Tomcat setup which uses "localhost" and saw
"jndi:/localhost/myapp/". I then changed Tomcat's configuration to name my
host something else (and changed my Windows "hosts" file as required). The
"localhost" changed appropriately. This means the pattern of that resource,
at least on Tomcat 5.0.2X, is "jndi:/HOSTNAME/APPNAME/". That means you can
split it into http://HOSTNAME/APPNAME for your app-loading SOAP steps.
Again, the big IF requires the leap of faith for conditions a) and b) above.
How does that idea work for you?
Regards,
David, happy at finding a conditional answer that works on his one-tested
Java server.
-Original Message-
From: Martin Wegner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 26, 2005 3:57 PM
To: Struts Users Mailing List
Subject: RE: PlugIn and the base URL
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: PlugIn and the base URL
It sounds to me like you don't have much choice here, your going to need some sort of config file with the URL. I myself would prefer the suggestion I made about updating the WAR via batch/shell script. I think this would be the easiest for your clients, and gets around all the other problems. 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, et
RE: PlugIn and the base URL
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' stat
RE: PlugIn and the base URL
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 Con
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 info
RE: PlugIn and the base URL
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]
RE: PlugIn and the base URL
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, 20
RE: PlugIn and the base URL
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
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]
RE: PlugIn and the base URL
WdJ, I like how you think with those ideas on first-time initalizations. Now if we can get Martin's feedback on if this would work for him. :) Regards, David -Original Message- From: Wiebe de Jong [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 26, 2005 1:52 PM To: 'Struts Users Mailing List' Subject: RE: PlugIn and the base URL 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]
RE: PlugIn and the base URL
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]
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]
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 > > > __ > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > > e-mail in error, please notify the sender immediately and destroy it. > As its integrity cannot be secured on the Internet, the Atos Origin > group > liability cannot be triggered for the message content. Although the > sender endeavours to maintain a computer virus-free network, the sender > does not warrant that this transmission is virus-free and will not be > liable for any damages resulting from any virus transmitted. > __ > > - > 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]
RE: PlugIn and the base URL
> > 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 __ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PlugIn and the base URL
Cedric, No doubt it is confusing. I admit it is an odd requirement. 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. So when the WS call comes in the Axis-based call dispatcher invokes some of the business objects that are shared by the Struts app. The business objects eventually create the WS response DOM. One of the attributes has to be the URL that was used to reach the WS. So if at startup my Struts app can figure out the URL it can configure the business objects with the SOAP URL and then the SOAP dispatcher can pick up that value to throw into the response DOM. Hope that makes sense. --Marty --- Cedric Levieux <[EMAIL PROTECTED]> wrote: > > My Struts app contains an Axis-based SOAP service. The Struts app > > initializes the call dispatcher for the SOAP service. This dispatcher > > needs to know the URL of itself. This is a requirement of the > semantics > > of the SOAP service (outside of my control). So a Listener or a Plug > In > > appear to be the only way to try to determine the URL before the SOAP > > service is open for business. > > I don't understand this point in fact, cause in ones of my working > struts > applications there are some > axis-soap web services and I didn't need to give my url path to > axis-soap. > > So i'm very confuse in fact .. > > Cedric > > > - > 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]
Re: PlugIn and the base URL
What about configuring something at the servlet container level, rather than web app. Tomcat allows you to you to configure JNDI resources, but I have no experiece of other servlet containers: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-resources-howto.html Niall - Original Message - From: "Martin Wegner" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" Sent: Wednesday, January 26, 2005 3:27 PM Subject: Re: PlugIn and the base URL > Niall, > > That would. Except it would require our customer to copy the WAR file to > the webapps directory, start Tomcat, wait a bit, stop Tomcat, find the > struts-config.xml file, edit it, save it and then start Tomcat again. Or > I could put the URL is an external config file, outside of the WAR file, > that if it exists is used by the web app. > > Both are viable options. If the web app can figure out the URL on its own > then it would be foolproof. > > Thanks. > > > --Marty > > --- Niall Pemberton <[EMAIL PROTECTED]> wrote: > > > Wouldn't the simplest thing be to just add a "url" property to the > > PlugIn > > that initializes your SOAP service? > > > > > > > value="http://blahblahblah.com:8080/AppName/"/> > > > > > > Niall > > > > ----- Original Message - > > From: "Martin Wegner" <[EMAIL PROTECTED]> > > To: "Struts Users Mailing List" > > Sent: Wednesday, January 26, 2005 3:12 PM > > Subject: RE: PlugIn and the base URL > > > > > > > David, > > > > > > My Struts app contains an Axis-based SOAP service. The Struts app > > > initializes the call dispatcher for the SOAP service. This dispatcher > > > needs to know the URL of itself. This is a requirement of the > > semantics > > > of the SOAP service (outside of my control). So a Listener or a Plug > > In > > > appear to be the only way to try to determine the URL before the SOAP > > > service is open for business. > > > > > > Thanks. > > > > > > > > > --Marty > > > > > > --- David Suarez <[EMAIL PROTECTED]> wrote: > > > > > > > Is your plug-in a 3rd party type component? What is the purpose of > > > > obtaining the URL? Maybe there's a suitable alternative depending > > on > > > > your requirements (ie. A Filter that would instantiate the objects > > you > > > > need to populate on the first request? A base action that lazy > > loads > > > > your config stuff?) > > > > > > > > Just a thought...djsuarez > > > > > > > > -Original Message- > > > > From: Martin Wegner [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday, January 26, 2005 12:18 AM > > > > To: Struts Users Mailing List; Dakota Jack > > > > Subject: Re: PlugIn and the base URL > > > > > > > > > > > > I am looking for the: > > > > > > > > http://blahblahblah.com:8080/AppName/ > > > > > > > > As Craig said I can get that if I have a Request object. But from a > > > > PlugIn I don't have that. I can think of some ugly hacks but > > nothing > > > > clean. > > > > > > > > > > > > --Marty > > > > > > > > --- Dakota Jack <[EMAIL PROTECTED]> wrote: > > > > > > > > > Do you want the URL or the Internet Protocol address? I have some > > > > > ideas on the latter. > > > > > > > > > > Jack > > > > > > > > > > > > > > > On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > Jack, > > > > > > > > > > > > That tells me where the JAR files are stored which is cool. But > > > > what > > > > > I am > > > > > > looking for a valid URL (of which there may be many) to access > > my > > > > > given > > > > > > web application. This info has to come from the container which > > may > > > > > be > > > > > > the problem. I don't see anything in the container standard > > which > > > > > > provides this info. > > > > > > > > > > > > Any other ideas? > > > > > > > > > > > > --Marty > > > >
Re: PlugIn and the base URL
> My Struts app contains an Axis-based SOAP service. The Struts app > initializes the call dispatcher for the SOAP service. This dispatcher > needs to know the URL of itself. This is a requirement of the semantics > of the SOAP service (outside of my control). So a Listener or a Plug In > appear to be the only way to try to determine the URL before the SOAP > service is open for business. I don't understand this point in fact, cause in ones of my working struts applications there are some axis-soap web services and I didn't need to give my url path to axis-soap. So i'm very confuse in fact .. Cedric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PlugIn and the base URL
I may be misunderstanding something, is your flow?
1. WS Caller --> Axis --> Struts call
2. WS Caller --> Struts --> Axis call
3. Some funky call-back combination?
Sounds like Axis/Struts are on the same box/servlet context as well from
your description below. A filter can run on any URL mapped request so
depending on your flow you should be able to instantiate what you need
to.
If you have a web service, a well-defined end-point is pretty mandatory
so pulling it from config doesn't seem to break any type of
encapsulation rules. Any reason why you don't want to have the location
in config as someone else mentioned?
Regards...djsuarez
-Original Message-
From: Martin Wegner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 26, 2005 9:12 AM
To: Struts Users Mailing List
Subject: RE: PlugIn and the base URL
David,
My Struts app contains an Axis-based SOAP service. The Struts app
initializes the call dispatcher for the SOAP service. This dispatcher
needs to know the URL of itself. This is a requirement of the semantics
of the SOAP service (outside of my control). So a Listener or a Plug In
appear to be the only way to try to determine the URL before the SOAP
service is open for business.
Thanks.
--Marty
--- David Suarez <[EMAIL PROTECTED]> wrote:
> Is your plug-in a 3rd party type component? What is the purpose of
> obtaining the URL? Maybe there's a suitable alternative depending on
> your requirements (ie. A Filter that would instantiate the objects you
> need to populate on the first request? A base action that lazy loads
> your config stuff?)
>
> Just a thought...djsuarez
>
> -Original Message-
> From: Martin Wegner [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 26, 2005 12:18 AM
> To: Struts Users Mailing List; Dakota Jack
> Subject: Re: PlugIn and the base URL
>
>
> I am looking for the:
>
> http://blahblahblah.com:8080/AppName/
>
> As Craig said I can get that if I have a Request object. But from a
> PlugIn I don't have that. I can think of some ugly hacks but nothing
> clean.
>
>
> --Marty
>
> --- Dakota Jack <[EMAIL PROTECTED]> wrote:
>
> > Do you want the URL or the Internet Protocol address? I have some
> > ideas on the latter.
> >
> > Jack
> >
> >
> > On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner
> > <[EMAIL PROTECTED]> wrote:
> > > Jack,
> > >
> > > That tells me where the JAR files are stored which is cool. But
> what
> > I am
> > > looking for a valid URL (of which there may be many) to access my
> > given
> > > web application. This info has to come from the container which
may
> > be
> > > the problem. I don't see anything in the container standard which
> > > provides this info.
> > >
> > > Any other ideas?
> > >
> > > --Marty
> > >
> > > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> > >
> > > > Not sure what you want. Does this help?
> > > >
> > > > package whatever;
> > > >
> > > > import java.io.File;
> > > > import java.net.URL;
> > > >
> > > > public final class Classpath {
> > > > public static final String SLASH= File.separator;
> > > > public static final String HERE =
> > > > Classpath.class.getClassLoader().getResource("whatever" + SLASH
+
> > > >
> > > > "Classpath.class").getFile();
> > > > }
> > > >
> > > >
> > > > On Tue, 25 Jan 2005 19:25:21 -0800 (PST), Martin Wegner
> > > > <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > As far as I can tell the attributes offer no insight. I have
> yet
> > to
> > > > find
> > > > > a way to get to the container from within a PlugIn. But I
will
> > keep
> > > > > looking. Using an initParam is not an option in this
> application.
> > > > >
> > > > > --Marty
> > > > >
> > > > > --- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > > The OP was looking for a way to construct the entire path.
I
> > too
> > > > got as
> > > > > >
> > > > > > far as ServletContext, but I'm not sure what in it would
give
> > you
> > > > that,
> > > > > > or even all the pieces to constuct it... Maybe
getAttribute()?
>
> > I'm
> > > >
Re: PlugIn and the base URL
Alternatively, you could create a batch file (or shell script for *nix systems) that updates the WAR with a config file that contains nothing but the URL (maybe just a .properties file in WEB-INF, nothing more). The plugin could use that. Then you ship the batch/script file, WAR and config file to your customers, have them edit the config file, run the batch/script file, then deploy. That would be a bit less onerous than the deploy/stop/edit/redeploy you describe. Probably not something the customer would complain about too much (I understand the desire to not have to anything like that of course). -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, January 26, 2005 10:27 am, Martin Wegner said: > Niall, > > That would. Except it would require our customer to copy the WAR file to > the webapps directory, start Tomcat, wait a bit, stop Tomcat, find the > struts-config.xml file, edit it, save it and then start Tomcat again. Or > I could put the URL is an external config file, outside of the WAR file, > that if it exists is used by the web app. > > Both are viable options. If the web app can figure out the URL on its own > then it would be foolproof. > > Thanks. > > > --Marty > > --- Niall Pemberton <[EMAIL PROTECTED]> wrote: > >> Wouldn't the simplest thing be to just add a "url" property to the >> PlugIn >> that initializes your SOAP service? >> >> >> > value="http://blahblahblah.com:8080/AppName/"/> >> >> >> Niall >> >> - Original Message ----- >> From: "Martin Wegner" <[EMAIL PROTECTED]> >> To: "Struts Users Mailing List" >> Sent: Wednesday, January 26, 2005 3:12 PM >> Subject: RE: PlugIn and the base URL >> >> >> > David, >> > >> > My Struts app contains an Axis-based SOAP service. The Struts app >> > initializes the call dispatcher for the SOAP service. This dispatcher >> > needs to know the URL of itself. This is a requirement of the >> semantics >> > of the SOAP service (outside of my control). So a Listener or a Plug >> In >> > appear to be the only way to try to determine the URL before the SOAP >> > service is open for business. >> > >> > Thanks. >> > >> > >> > --Marty >> > >> > --- David Suarez <[EMAIL PROTECTED]> wrote: >> > >> > > Is your plug-in a 3rd party type component? What is the purpose of >> > > obtaining the URL? Maybe there's a suitable alternative depending >> on >> > > your requirements (ie. A Filter that would instantiate the objects >> you >> > > need to populate on the first request? A base action that lazy >> loads >> > > your config stuff?) >> > > >> > > Just a thought...djsuarez >> > > >> > > -Original Message- >> > > From: Martin Wegner [mailto:[EMAIL PROTECTED] >> > > Sent: Wednesday, January 26, 2005 12:18 AM >> > > To: Struts Users Mailing List; Dakota Jack >> > > Subject: Re: PlugIn and the base URL >> > > >> > > >> > > I am looking for the: >> > > >> > > http://blahblahblah.com:8080/AppName/ >> > > >> > > As Craig said I can get that if I have a Request object. But from a >> > > PlugIn I don't have that. I can think of some ugly hacks but >> nothing >> > > clean. >> > > >> > > >> > > --Marty >> > > >> > > --- Dakota Jack <[EMAIL PROTECTED]> wrote: >> > > >> > > > Do you want the URL or the Internet Protocol address? I have some >> > > > ideas on the latter. >> > > > >> > > > Jack >> > > > >> > > > >> > > > On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner >> > > > <[EMAIL PROTECTED]> wrote: >> > > > > Jack, >> > > > > >> > > > > That tells me where the JAR files are stored which is cool. But >> > > what >> > > > I am >> > > > > looking for a valid URL (of which there may be many) to access >> my >> > > > given >> > > > > web application. This info has to come from the container which >> may >> > > > be >> > > > > the problem. I don't see anything in the container standard >> which >> >
Re: PlugIn and the base URL
Niall,
That would. Except it would require our customer to copy the WAR file to
the webapps directory, start Tomcat, wait a bit, stop Tomcat, find the
struts-config.xml file, edit it, save it and then start Tomcat again. Or
I could put the URL is an external config file, outside of the WAR file,
that if it exists is used by the web app.
Both are viable options. If the web app can figure out the URL on its own
then it would be foolproof.
Thanks.
--Marty
--- Niall Pemberton <[EMAIL PROTECTED]> wrote:
> Wouldn't the simplest thing be to just add a "url" property to the
> PlugIn
> that initializes your SOAP service?
>
>
> value="http://blahblahblah.com:8080/AppName/"/>
>
>
> Niall
>
> - Original Message -
> From: "Martin Wegner" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List"
> Sent: Wednesday, January 26, 2005 3:12 PM
> Subject: RE: PlugIn and the base URL
>
>
> > David,
> >
> > My Struts app contains an Axis-based SOAP service. The Struts app
> > initializes the call dispatcher for the SOAP service. This dispatcher
> > needs to know the URL of itself. This is a requirement of the
> semantics
> > of the SOAP service (outside of my control). So a Listener or a Plug
> In
> > appear to be the only way to try to determine the URL before the SOAP
> > service is open for business.
> >
> > Thanks.
> >
> >
> > --Marty
> >
> > --- David Suarez <[EMAIL PROTECTED]> wrote:
> >
> > > Is your plug-in a 3rd party type component? What is the purpose of
> > > obtaining the URL? Maybe there's a suitable alternative depending
> on
> > > your requirements (ie. A Filter that would instantiate the objects
> you
> > > need to populate on the first request? A base action that lazy
> loads
> > > your config stuff?)
> > >
> > > Just a thought...djsuarez
> > >
> > > -Original Message-
> > > From: Martin Wegner [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, January 26, 2005 12:18 AM
> > > To: Struts Users Mailing List; Dakota Jack
> > > Subject: Re: PlugIn and the base URL
> > >
> > >
> > > I am looking for the:
> > >
> > > http://blahblahblah.com:8080/AppName/
> > >
> > > As Craig said I can get that if I have a Request object. But from a
> > > PlugIn I don't have that. I can think of some ugly hacks but
> nothing
> > > clean.
> > >
> > >
> > > --Marty
> > >
> > > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> > >
> > > > Do you want the URL or the Internet Protocol address? I have some
> > > > ideas on the latter.
> > > >
> > > > Jack
> > > >
> > > >
> > > > On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner
> > > > <[EMAIL PROTECTED]> wrote:
> > > > > Jack,
> > > > >
> > > > > That tells me where the JAR files are stored which is cool. But
> > > what
> > > > I am
> > > > > looking for a valid URL (of which there may be many) to access
> my
> > > > given
> > > > > web application. This info has to come from the container which
> may
> > > > be
> > > > > the problem. I don't see anything in the container standard
> which
> > > > > provides this info.
> > > > >
> > > > > Any other ideas?
> > > > >
> > > > > --Marty
> > > > >
> > > > > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > > Not sure what you want. Does this help?
> > > > > >
> > > > > > package whatever;
> > > > > >
> > > > > > import java.io.File;
> > > > > > import java.net.URL;
> > > > > >
> > > > > > public final class Classpath {
> > > > > > public static final String SLASH= File.separator;
> > > > > > public static final String HERE =
> > > > > > Classpath.class.getClassLoader().getResource("whatever" +
> SLASH +
> > > > > >
> > > > > > "Classpath.class").getFile();
> > > > > > }
> > > > > >
> > > > > >
> > > > > > On Tue, 25 Jan 2005 19:25:21 -0800 (PST), Martin Wegner
>
Re: PlugIn and the base URL
Wouldn't the simplest thing be to just add a "url" property to the PlugIn
that initializes your SOAP service?
http://blahblahblah.com:8080/AppName/"/>
Niall
- Original Message -
From: "Martin Wegner" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List"
Sent: Wednesday, January 26, 2005 3:12 PM
Subject: RE: PlugIn and the base URL
> David,
>
> My Struts app contains an Axis-based SOAP service. The Struts app
> initializes the call dispatcher for the SOAP service. This dispatcher
> needs to know the URL of itself. This is a requirement of the semantics
> of the SOAP service (outside of my control). So a Listener or a Plug In
> appear to be the only way to try to determine the URL before the SOAP
> service is open for business.
>
> Thanks.
>
>
> --Marty
>
> --- David Suarez <[EMAIL PROTECTED]> wrote:
>
> > Is your plug-in a 3rd party type component? What is the purpose of
> > obtaining the URL? Maybe there's a suitable alternative depending on
> > your requirements (ie. A Filter that would instantiate the objects you
> > need to populate on the first request? A base action that lazy loads
> > your config stuff?)
> >
> > Just a thought...djsuarez
> >
> > -Original Message-
> > From: Martin Wegner [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, January 26, 2005 12:18 AM
> > To: Struts Users Mailing List; Dakota Jack
> > Subject: Re: PlugIn and the base URL
> >
> >
> > I am looking for the:
> >
> > http://blahblahblah.com:8080/AppName/
> >
> > As Craig said I can get that if I have a Request object. But from a
> > PlugIn I don't have that. I can think of some ugly hacks but nothing
> > clean.
> >
> >
> > --Marty
> >
> > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> >
> > > Do you want the URL or the Internet Protocol address? I have some
> > > ideas on the latter.
> > >
> > > Jack
> > >
> > >
> > > On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner
> > > <[EMAIL PROTECTED]> wrote:
> > > > Jack,
> > > >
> > > > That tells me where the JAR files are stored which is cool. But
> > what
> > > I am
> > > > looking for a valid URL (of which there may be many) to access my
> > > given
> > > > web application. This info has to come from the container which may
> > > be
> > > > the problem. I don't see anything in the container standard which
> > > > provides this info.
> > > >
> > > > Any other ideas?
> > > >
> > > > --Marty
> > > >
> > > > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Not sure what you want. Does this help?
> > > > >
> > > > > package whatever;
> > > > >
> > > > > import java.io.File;
> > > > > import java.net.URL;
> > > > >
> > > > > public final class Classpath {
> > > > > public static final String SLASH= File.separator;
> > > > > public static final String HERE =
> > > > > Classpath.class.getClassLoader().getResource("whatever" + SLASH +
> > > > >
> > > > > "Classpath.class").getFile();
> > > > > }
> > > > >
> > > > >
> > > > > On Tue, 25 Jan 2005 19:25:21 -0800 (PST), Martin Wegner
> > > > > <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > As far as I can tell the attributes offer no insight. I have
> > yet
> > > to
> > > > > find
> > > > > > a way to get to the container from within a PlugIn. But I will
> > > keep
> > > > > > looking. Using an initParam is not an option in this
> > application.
> > > > > >
> > > > > > --Marty
> > > > > >
> > > > > > --- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > > The OP was looking for a way to construct the entire path. I
> > > too
> > > > > got as
> > > > > > >
> > > > > > > far as ServletContext, but I'm not sure what in it would give
> > > you
> > > > > that,
> > > > > > > or even all the pieces to constuct it... Maybe getAttrib
RE: PlugIn and the base URL
Frank,
Yeah, that was the one hack that came to mind yesterday. It would
definitely work. If there is no alternative that is what I will have to
do. But I am hoping that the Struts gurus have a better answer in their
pocket.
Thanks.
--Marty
--- [EMAIL PROTECTED] wrote:
> Just thinking out loud here, but...
>
> What if from your plug-in you spawn a thread that will:
>
> (1) Wait a few second, to allow the app to otherwise initialize
> completely
> (2) Make a request to a special Action that will do the rest of the
> initialization that requires the URL (should be able to do
> http://localhost/myapp)
> (3) Die
>
> I do something similar for database initialization... I spaw a thread
> from the plug-in, wait a few seconds, then make a call to my database
> connection manager class, which has the effect of creating the
> connection pool. This way I know it's done before the first request
> comes in. Similar kind of idea.
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> On Wed, January 26, 2005 10:12 am, Martin Wegner said:
> > David,
> >
> > My Struts app contains an Axis-based SOAP service. The Struts app
> > initializes the call dispatcher for the SOAP service. This dispatcher
> > needs to know the URL of itself. This is a requirement of the
> semantics
> > of the SOAP service (outside of my control). So a Listener or a Plug
> In
> > appear to be the only way to try to determine the URL before the SOAP
> > service is open for business.
> >
> > Thanks.
> >
> >
> > --Marty
> >
> > --- David Suarez <[EMAIL PROTECTED]> wrote:
> >
> >> Is your plug-in a 3rd party type component? What is the purpose of
> >> obtaining the URL? Maybe there's a suitable alternative depending on
> >> your requirements (ie. A Filter that would instantiate the objects
> you
> >> need to populate on the first request? A base action that lazy loads
> >> your config stuff?)
> >>
> >> Just a thought...djsuarez
> >>
> >> -Original Message-
> >> From: Martin Wegner [mailto:[EMAIL PROTECTED]
> >> Sent: Wednesday, January 26, 2005 12:18 AM
> >> To: Struts Users Mailing List; Dakota Jack
> >> Subject: Re: PlugIn and the base URL
> >>
> >>
> >> I am looking for the:
> >>
> >> http://blahblahblah.com:8080/AppName/
> >>
> >> As Craig said I can get that if I have a Request object. But from a
> >> PlugIn I don't have that. I can think of some ugly hacks but nothing
> >> clean.
> >>
> >>
> >> --Marty
> >>
> >> --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> >>
> >> > Do you want the URL or the Internet Protocol address? I have some
> >> > ideas on the latter.
> >> >
> >> > Jack
> >> >
> >> >
> >> > On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner
> >> > <[EMAIL PROTECTED]> wrote:
> >> > > Jack,
> >> > >
> >> > > That tells me where the JAR files are stored which is cool. But
> >> what
> >> > I am
> >> > > looking for a valid URL (of which there may be many) to access my
> >> > given
> >> > > web application. This info has to come from the container which
> may
> >> > be
> >> > > the problem. I don't see anything in the container standard
> which
> >> > > provides this info.
> >> > >
> >> > > Any other ideas?
> >> > >
> >> > > --Marty
> >> > >
> >> > > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> >> > >
> >> > > > Not sure what you want. Does this help?
> >> > > >
> >> > > > package whatever;
> >> > > >
> >> > > > import java.io.File;
> >> > > > import java.net.URL;
> >> > > >
> >> > > > public final class Classpath {
> >> > > > public static final String SLASH= File.separator;
> >> > > > public static final String HERE =
> >> > > > Classpath.class.getClassLoader().getResource("whatever" + SLASH
> +
> >> > > >
> >> > > > "Classpath.class").getFile();
> >> > > > }
> >> > > >
> >> &g
RE: PlugIn and the base URL
Just thinking out loud here, but...
What if from your plug-in you spawn a thread that will:
(1) Wait a few second, to allow the app to otherwise initialize completely
(2) Make a request to a special Action that will do the rest of the
initialization that requires the URL (should be able to do
http://localhost/myapp)
(3) Die
I do something similar for database initialization... I spaw a thread from the
plug-in, wait a few seconds, then make a call to my database connection manager
class, which has the effect of creating the connection pool. This way I know
it's done before the first request comes in. Similar kind of idea.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Wed, January 26, 2005 10:12 am, Martin Wegner said:
> David,
>
> My Struts app contains an Axis-based SOAP service. The Struts app
> initializes the call dispatcher for the SOAP service. This dispatcher
> needs to know the URL of itself. This is a requirement of the semantics
> of the SOAP service (outside of my control). So a Listener or a Plug In
> appear to be the only way to try to determine the URL before the SOAP
> service is open for business.
>
> Thanks.
>
>
> --Marty
>
> --- David Suarez <[EMAIL PROTECTED]> wrote:
>
>> Is your plug-in a 3rd party type component? What is the purpose of
>> obtaining the URL? Maybe there's a suitable alternative depending on
>> your requirements (ie. A Filter that would instantiate the objects you
>> need to populate on the first request? A base action that lazy loads
>> your config stuff?)
>>
>> Just a thought...djsuarez
>>
>> -Original Message-
>> From: Martin Wegner [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, January 26, 2005 12:18 AM
>> To: Struts Users Mailing List; Dakota Jack
>> Subject: Re: PlugIn and the base URL
>>
>>
>> I am looking for the:
>>
>> http://blahblahblah.com:8080/AppName/
>>
>> As Craig said I can get that if I have a Request object. But from a
>> PlugIn I don't have that. I can think of some ugly hacks but nothing
>> clean.
>>
>>
>> --Marty
>>
>> --- Dakota Jack <[EMAIL PROTECTED]> wrote:
>>
>> > Do you want the URL or the Internet Protocol address? I have some
>> > ideas on the latter.
>> >
>> > Jack
>> >
>> >
>> > On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner
>> > <[EMAIL PROTECTED]> wrote:
>> > > Jack,
>> > >
>> > > That tells me where the JAR files are stored which is cool. But
>> what
>> > I am
>> > > looking for a valid URL (of which there may be many) to access my
>> > given
>> > > web application. This info has to come from the container which may
>> > be
>> > > the problem. I don't see anything in the container standard which
>> > > provides this info.
>> > >
>> > > Any other ideas?
>> > >
>> > > --Marty
>> > >
>> > > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
>> > >
>> > > > Not sure what you want. Does this help?
>> > > >
>> > > > package whatever;
>> > > >
>> > > > import java.io.File;
>> > > > import java.net.URL;
>> > > >
>> > > > public final class Classpath {
>> > > > public static final String SLASH= File.separator;
>> > > > public static final String HERE =
>> > > > Classpath.class.getClassLoader().getResource("whatever" + SLASH +
>> > > >
>> > > > "Classpath.class").getFile();
>> > > > }
>> > > >
>> > > >
>> > > > On Tue, 25 Jan 2005 19:25:21 -0800 (PST), Martin Wegner
>> > > > <[EMAIL PROTECTED]> wrote:
>> > > > >
>> > > > > As far as I can tell the attributes offer no insight. I have
>> yet
>> > to
>> > > > find
>> > > > > a way to get to the container from within a PlugIn. But I will
>> > keep
>> > > > > looking. Using an initParam is not an option in this
>> application.
>> > > > >
>> > > > > --Marty
>> > > > >
>> > > > > --- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote:
>> > > > >
>> > > > > > The OP was looking for a way to construct the entire path. I
>> &
RE: PlugIn and the base URL
David,
My Struts app contains an Axis-based SOAP service. The Struts app
initializes the call dispatcher for the SOAP service. This dispatcher
needs to know the URL of itself. This is a requirement of the semantics
of the SOAP service (outside of my control). So a Listener or a Plug In
appear to be the only way to try to determine the URL before the SOAP
service is open for business.
Thanks.
--Marty
--- David Suarez <[EMAIL PROTECTED]> wrote:
> Is your plug-in a 3rd party type component? What is the purpose of
> obtaining the URL? Maybe there's a suitable alternative depending on
> your requirements (ie. A Filter that would instantiate the objects you
> need to populate on the first request? A base action that lazy loads
> your config stuff?)
>
> Just a thought...djsuarez
>
> -Original Message-
> From: Martin Wegner [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 26, 2005 12:18 AM
> To: Struts Users Mailing List; Dakota Jack
> Subject: Re: PlugIn and the base URL
>
>
> I am looking for the:
>
> http://blahblahblah.com:8080/AppName/
>
> As Craig said I can get that if I have a Request object. But from a
> PlugIn I don't have that. I can think of some ugly hacks but nothing
> clean.
>
>
> --Marty
>
> --- Dakota Jack <[EMAIL PROTECTED]> wrote:
>
> > Do you want the URL or the Internet Protocol address? I have some
> > ideas on the latter.
> >
> > Jack
> >
> >
> > On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner
> > <[EMAIL PROTECTED]> wrote:
> > > Jack,
> > >
> > > That tells me where the JAR files are stored which is cool. But
> what
> > I am
> > > looking for a valid URL (of which there may be many) to access my
> > given
> > > web application. This info has to come from the container which may
> > be
> > > the problem. I don't see anything in the container standard which
> > > provides this info.
> > >
> > > Any other ideas?
> > >
> > > --Marty
> > >
> > > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> > >
> > > > Not sure what you want. Does this help?
> > > >
> > > > package whatever;
> > > >
> > > > import java.io.File;
> > > > import java.net.URL;
> > > >
> > > > public final class Classpath {
> > > > public static final String SLASH= File.separator;
> > > > public static final String HERE =
> > > > Classpath.class.getClassLoader().getResource("whatever" + SLASH +
> > > >
> > > > "Classpath.class").getFile();
> > > > }
> > > >
> > > >
> > > > On Tue, 25 Jan 2005 19:25:21 -0800 (PST), Martin Wegner
> > > > <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > As far as I can tell the attributes offer no insight. I have
> yet
> > to
> > > > find
> > > > > a way to get to the container from within a PlugIn. But I will
> > keep
> > > > > looking. Using an initParam is not an option in this
> application.
> > > > >
> > > > > --Marty
> > > > >
> > > > > --- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > > The OP was looking for a way to construct the entire path. I
> > too
> > > > got as
> > > > > >
> > > > > > far as ServletContext, but I'm not sure what in it would give
> > you
> > > > that,
> > > > > > or even all the pieces to constuct it... Maybe getAttribute()?
>
> > I'm
> > > > not
> > > > > > sure what it will return, although you can use
> > getAttributeNames()
> > > > to
> > > > > > see. The Javadocs indicates the attributes are
> > container-specific
> > > > > > though, so I'm not sure he'd want to use that anyway.
> > > > > >
> > > > > > This is just a matter of curiosity for me at this point, I
> long
> > ago
> > > > > > solved this problem another way. I'd like to know how to do
> it
> > > > though.
> > > > > >
> > > > > > --
> > > > > > Frank W. Zammetti
> > > > > > Founder and Chief Software Architect
> > > > > > Omnytex Technologies
> > > > > > http://www
Re: PlugIn and the base URL
I need to find the URL of my web app at start up. I need it as soon as
possible in the boot process. So Listerners and Plug Ins are the only two
ways I know of that allow me to hook into the startup of the app. Is
there another mechanism available?
--Marty
--- Larry Meadors <[EMAIL PROTECTED]> wrote:
> why does it have to be a plugin?
>
>
> On Tue, 25 Jan 2005 22:18:20 -0800 (PST), Martin Wegner
> <[EMAIL PROTECTED]> wrote:
> >
> > I am looking for the:
> >
> > http://blahblahblah.com:8080/AppName/
> >
> > As Craig said I can get that if I have a Request object. But from a
> > PlugIn I don't have that. I can think of some ugly hacks but nothing
> > clean.
> >
> >
> > --Marty
> >
> > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> >
> > > Do you want the URL or the Internet Protocol address? I have some
> > > ideas on the latter.
> > >
> > > Jack
> > >
> > >
> > > On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner
> > > <[EMAIL PROTECTED]> wrote:
> > > > Jack,
> > > >
> > > > That tells me where the JAR files are stored which is cool. But
> what
> > > I am
> > > > looking for a valid URL (of which there may be many) to access my
> > > given
> > > > web application. This info has to come from the container which
> may
> > > be
> > > > the problem. I don't see anything in the container standard which
> > > > provides this info.
> > > >
> > > > Any other ideas?
> > > >
> > > > --Marty
> > > >
> > > > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Not sure what you want. Does this help?
> > > > >
> > > > > package whatever;
> > > > >
> > > > > import java.io.File;
> > > > > import java.net.URL;
> > > > >
> > > > > public final class Classpath {
> > > > > public static final String SLASH= File.separator;
> > > > > public static final String HERE =
> > > > > Classpath.class.getClassLoader().getResource("whatever" + SLASH
> +
> > > > >
> > > > > "Classpath.class").getFile();
> > > > > }
> > > > >
> > > > >
> > > > > On Tue, 25 Jan 2005 19:25:21 -0800 (PST), Martin Wegner
> > > > > <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > As far as I can tell the attributes offer no insight. I have
> yet
> > > to
> > > > > find
> > > > > > a way to get to the container from within a PlugIn. But I
> will
> > > keep
> > > > > > looking. Using an initParam is not an option in this
> application.
> > > > > >
> > > > > > --Marty
> > > > > >
> > > > > > --- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > > The OP was looking for a way to construct the entire path.
> I
> > > too
> > > > > got as
> > > > > > >
> > > > > > > far as ServletContext, but I'm not sure what in it would
> give
> > > you
> > > > > that,
> > > > > > > or even all the pieces to constuct it... Maybe
> getAttribute()?
> > > I'm
> > > > > not
> > > > > > > sure what it will return, although you can use
> > > getAttributeNames()
> > > > > to
> > > > > > > see. The Javadocs indicates the attributes are
> > > container-specific
> > > > > > > though, so I'm not sure he'd want to use that anyway.
> > > > > > >
> > > > > > > This is just a matter of curiosity for me at this point, I
> long
> > > ago
> > > > > > > solved this problem another way. I'd like to know how to do
> it
> > > > > though.
> > > > > > >
> > > > > > > --
> > > > > > > Frank W. Zammetti
> > > > > > > Founder and Chief Software Architect
> > > > > > > Omnytex Technologies
> > > > > > > http://www.omnytex.com
> > > > > > >
> > > > > > >
> > > > > > > Jim Barrows wrote:
> > > > > > > > On Tue, 25 Jan 2005 18:37:29 -0500, Frank W. Zammetti
> > > > > > > > <[EMAIL PROTECTED]> wrote:
> > > > > > > >
> > > > > > > >>I seem to remember trying to solve this problem myself and
> > > coming
> > > > > to
> > > > > > > the
> > > > > > > >>conclusion that there was no way to do it independent of a
> > > > > request. I
> > > > > > > >>wound up just sticking it in my application config file
> that
> > > gets
> > > > > read
> > > > > > > >>in the plugin anyway. Can anyone prove me wrong? :)
> > > > > > > >
> > > > > > > >
> > > > > > > > Your looking for the application context correct?
> > > > > > > > In the init you are passed the ActionServlet, which
> inherits
> > > from
> > > > > > > > HttpServlet, which will give you the ServletContext. IIRC
> you
> > > can
> > > > > get
> > > > > > > > the context from there.
> > > > > > > >
> > > > > > > >
> > > > > > > >>--
> > > > > > > >>Frank W. Zammetti
> > > > > > > >>Founder and Chief Software Architect
> > > > > > > >>Omnytex Technologies
> > > > > > > >>http://www.omnytex.com
> > > > > > > >>
> > > > > > > >>Martin Wegner wrote:
> > > > > > > >>
> > > > > > > >>>In have a Struts PlugIn that needs to determine the URL
> for
> > > the
> > > > > > > containing
> > > > > > > >>>web application (http://localhost:8080/BlahBlahBlah/). I
> am
> > > > > unable
> > > > > > > to
> > > > > > > >>>find a way to determine this information. Any ideas?
> > > > > > > >>>
> > > > > >
RE: PlugIn and the base URL
Is your plug-in a 3rd party type component? What is the purpose of
obtaining the URL? Maybe there's a suitable alternative depending on
your requirements (ie. A Filter that would instantiate the objects you
need to populate on the first request? A base action that lazy loads
your config stuff?)
Just a thought...djsuarez
-Original Message-
From: Martin Wegner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 26, 2005 12:18 AM
To: Struts Users Mailing List; Dakota Jack
Subject: Re: PlugIn and the base URL
I am looking for the:
http://blahblahblah.com:8080/AppName/
As Craig said I can get that if I have a Request object. But from a
PlugIn I don't have that. I can think of some ugly hacks but nothing
clean.
--Marty
--- Dakota Jack <[EMAIL PROTECTED]> wrote:
> Do you want the URL or the Internet Protocol address? I have some
> ideas on the latter.
>
> Jack
>
>
> On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner
> <[EMAIL PROTECTED]> wrote:
> > Jack,
> >
> > That tells me where the JAR files are stored which is cool. But
what
> I am
> > looking for a valid URL (of which there may be many) to access my
> given
> > web application. This info has to come from the container which may
> be
> > the problem. I don't see anything in the container standard which
> > provides this info.
> >
> > Any other ideas?
> >
> > --Marty
> >
> > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> >
> > > Not sure what you want. Does this help?
> > >
> > > package whatever;
> > >
> > > import java.io.File;
> > > import java.net.URL;
> > >
> > > public final class Classpath {
> > > public static final String SLASH= File.separator;
> > > public static final String HERE =
> > > Classpath.class.getClassLoader().getResource("whatever" + SLASH +
> > >
> > > "Classpath.class").getFile();
> > > }
> > >
> > >
> > > On Tue, 25 Jan 2005 19:25:21 -0800 (PST), Martin Wegner
> > > <[EMAIL PROTECTED]> wrote:
> > > >
> > > > As far as I can tell the attributes offer no insight. I have
yet
> to
> > > find
> > > > a way to get to the container from within a PlugIn. But I will
> keep
> > > > looking. Using an initParam is not an option in this
application.
> > > >
> > > > --Marty
> > > >
> > > > --- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > The OP was looking for a way to construct the entire path. I
> too
> > > got as
> > > > >
> > > > > far as ServletContext, but I'm not sure what in it would give
> you
> > > that,
> > > > > or even all the pieces to constuct it... Maybe getAttribute()?
> I'm
> > > not
> > > > > sure what it will return, although you can use
> getAttributeNames()
> > > to
> > > > > see. The Javadocs indicates the attributes are
> container-specific
> > > > > though, so I'm not sure he'd want to use that anyway.
> > > > >
> > > > > This is just a matter of curiosity for me at this point, I
long
> ago
> > > > > solved this problem another way. I'd like to know how to do
it
> > > though.
> > > > >
> > > > > --
> > > > > Frank W. Zammetti
> > > > > Founder and Chief Software Architect
> > > > > Omnytex Technologies
> > > > > http://www.omnytex.com
> > > > >
> > > > >
> > > > > Jim Barrows wrote:
> > > > > > On Tue, 25 Jan 2005 18:37:29 -0500, Frank W. Zammetti
> > > > > > <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > >>I seem to remember trying to solve this problem myself and
> coming
> > > to
> > > > > the
> > > > > >>conclusion that there was no way to do it independent of a
> > > request. I
> > > > > >>wound up just sticking it in my application config file that
> gets
> > > read
> > > > > >>in the plugin anyway. Can anyone prove me wrong? :)
> > > > > >
> > > > > >
> > > > >
Re: PlugIn and the base URL
why does it have to be a plugin?
On Tue, 25 Jan 2005 22:18:20 -0800 (PST), Martin Wegner
<[EMAIL PROTECTED]> wrote:
>
> I am looking for the:
>
> http://blahblahblah.com:8080/AppName/
>
> As Craig said I can get that if I have a Request object. But from a
> PlugIn I don't have that. I can think of some ugly hacks but nothing
> clean.
>
>
> --Marty
>
> --- Dakota Jack <[EMAIL PROTECTED]> wrote:
>
> > Do you want the URL or the Internet Protocol address? I have some
> > ideas on the latter.
> >
> > Jack
> >
> >
> > On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner
> > <[EMAIL PROTECTED]> wrote:
> > > Jack,
> > >
> > > That tells me where the JAR files are stored which is cool. But what
> > I am
> > > looking for a valid URL (of which there may be many) to access my
> > given
> > > web application. This info has to come from the container which may
> > be
> > > the problem. I don't see anything in the container standard which
> > > provides this info.
> > >
> > > Any other ideas?
> > >
> > > --Marty
> > >
> > > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> > >
> > > > Not sure what you want. Does this help?
> > > >
> > > > package whatever;
> > > >
> > > > import java.io.File;
> > > > import java.net.URL;
> > > >
> > > > public final class Classpath {
> > > > public static final String SLASH= File.separator;
> > > > public static final String HERE =
> > > > Classpath.class.getClassLoader().getResource("whatever" + SLASH +
> > > >
> > > > "Classpath.class").getFile();
> > > > }
> > > >
> > > >
> > > > On Tue, 25 Jan 2005 19:25:21 -0800 (PST), Martin Wegner
> > > > <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > As far as I can tell the attributes offer no insight. I have yet
> > to
> > > > find
> > > > > a way to get to the container from within a PlugIn. But I will
> > keep
> > > > > looking. Using an initParam is not an option in this application.
> > > > >
> > > > > --Marty
> > > > >
> > > > > --- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > > The OP was looking for a way to construct the entire path. I
> > too
> > > > got as
> > > > > >
> > > > > > far as ServletContext, but I'm not sure what in it would give
> > you
> > > > that,
> > > > > > or even all the pieces to constuct it... Maybe getAttribute()?
> > I'm
> > > > not
> > > > > > sure what it will return, although you can use
> > getAttributeNames()
> > > > to
> > > > > > see. The Javadocs indicates the attributes are
> > container-specific
> > > > > > though, so I'm not sure he'd want to use that anyway.
> > > > > >
> > > > > > This is just a matter of curiosity for me at this point, I long
> > ago
> > > > > > solved this problem another way. I'd like to know how to do it
> > > > though.
> > > > > >
> > > > > > --
> > > > > > Frank W. Zammetti
> > > > > > Founder and Chief Software Architect
> > > > > > Omnytex Technologies
> > > > > > http://www.omnytex.com
> > > > > >
> > > > > >
> > > > > > Jim Barrows wrote:
> > > > > > > On Tue, 25 Jan 2005 18:37:29 -0500, Frank W. Zammetti
> > > > > > > <[EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > >>I seem to remember trying to solve this problem myself and
> > coming
> > > > to
> > > > > > the
> > > > > > >>conclusion that there was no way to do it independent of a
> > > > request. I
> > > > > > >>wound up just sticking it in my application config file that
> > gets
> > > > read
> > > > > > >>in the plugin anyway. Can anyone prove me wrong? :)
> > > > > > >
> > > > > > >
> > > > > > > Your looking for the application context correct?
> > > > > > > In the init you are passed the ActionServlet, which inherits
> > from
> > > > > > > HttpServlet, which will give you the ServletContext. IIRC you
> > can
> > > > get
> > > > > > > the context from there.
> > > > > > >
> > > > > > >
> > > > > > >>--
> > > > > > >>Frank W. Zammetti
> > > > > > >>Founder and Chief Software Architect
> > > > > > >>Omnytex Technologies
> > > > > > >>http://www.omnytex.com
> > > > > > >>
> > > > > > >>Martin Wegner wrote:
> > > > > > >>
> > > > > > >>>In have a Struts PlugIn that needs to determine the URL for
> > the
> > > > > > containing
> > > > > > >>>web application (http://localhost:8080/BlahBlahBlah/). I am
> > > > unable
> > > > > > to
> > > > > > >>>find a way to determine this information. Any ideas?
> > > > > > >>>
> > > > > > >>>Thanks.
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>--Marty
> > > > > > >>>
> > > > > > >>>
> > > > > >
> > > >
> > >>>-
> > > > > > >>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > > >>>For additional commands, e-mail: [EMAIL PROTECTED]
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>.
> > > > > > >>>
> > > > > > >>
> > > > > >
> > > >
> > >>-
> > > > > > >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > > >>For additional commands, e-mail:
Re: PlugIn and the base URL
I am looking for the:
http://blahblahblah.com:8080/AppName/
As Craig said I can get that if I have a Request object. But from a
PlugIn I don't have that. I can think of some ugly hacks but nothing
clean.
--Marty
--- Dakota Jack <[EMAIL PROTECTED]> wrote:
> Do you want the URL or the Internet Protocol address? I have some
> ideas on the latter.
>
> Jack
>
>
> On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner
> <[EMAIL PROTECTED]> wrote:
> > Jack,
> >
> > That tells me where the JAR files are stored which is cool. But what
> I am
> > looking for a valid URL (of which there may be many) to access my
> given
> > web application. This info has to come from the container which may
> be
> > the problem. I don't see anything in the container standard which
> > provides this info.
> >
> > Any other ideas?
> >
> > --Marty
> >
> > --- Dakota Jack <[EMAIL PROTECTED]> wrote:
> >
> > > Not sure what you want. Does this help?
> > >
> > > package whatever;
> > >
> > > import java.io.File;
> > > import java.net.URL;
> > >
> > > public final class Classpath {
> > > public static final String SLASH= File.separator;
> > > public static final String HERE =
> > > Classpath.class.getClassLoader().getResource("whatever" + SLASH +
> > >
> > > "Classpath.class").getFile();
> > > }
> > >
> > >
> > > On Tue, 25 Jan 2005 19:25:21 -0800 (PST), Martin Wegner
> > > <[EMAIL PROTECTED]> wrote:
> > > >
> > > > As far as I can tell the attributes offer no insight. I have yet
> to
> > > find
> > > > a way to get to the container from within a PlugIn. But I will
> keep
> > > > looking. Using an initParam is not an option in this application.
> > > >
> > > > --Marty
> > > >
> > > > --- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > The OP was looking for a way to construct the entire path. I
> too
> > > got as
> > > > >
> > > > > far as ServletContext, but I'm not sure what in it would give
> you
> > > that,
> > > > > or even all the pieces to constuct it... Maybe getAttribute()?
> I'm
> > > not
> > > > > sure what it will return, although you can use
> getAttributeNames()
> > > to
> > > > > see. The Javadocs indicates the attributes are
> container-specific
> > > > > though, so I'm not sure he'd want to use that anyway.
> > > > >
> > > > > This is just a matter of curiosity for me at this point, I long
> ago
> > > > > solved this problem another way. I'd like to know how to do it
> > > though.
> > > > >
> > > > > --
> > > > > Frank W. Zammetti
> > > > > Founder and Chief Software Architect
> > > > > Omnytex Technologies
> > > > > http://www.omnytex.com
> > > > >
> > > > >
> > > > > Jim Barrows wrote:
> > > > > > On Tue, 25 Jan 2005 18:37:29 -0500, Frank W. Zammetti
> > > > > > <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > >>I seem to remember trying to solve this problem myself and
> coming
> > > to
> > > > > the
> > > > > >>conclusion that there was no way to do it independent of a
> > > request. I
> > > > > >>wound up just sticking it in my application config file that
> gets
> > > read
> > > > > >>in the plugin anyway. Can anyone prove me wrong? :)
> > > > > >
> > > > > >
> > > > > > Your looking for the application context correct?
> > > > > > In the init you are passed the ActionServlet, which inherits
> from
> > > > > > HttpServlet, which will give you the ServletContext. IIRC you
> can
> > > get
> > > > > > the context from there.
> > > > > >
> > > > > >
> > > > > >>--
> > > > > >>Frank W. Zammetti
> > > > > >>Founder and Chief Software Architect
> > > > > >>Omnytex Technologies
> > > > > >>http://www.omnytex.com
> > > > > >>
> > > > > >>Martin Wegner wrote:
> > > > > >>
> > > > > >>>In have a Struts PlugIn that needs to determine the URL for
> the
> > > > > containing
> > > > > >>>web application (http://localhost:8080/BlahBlahBlah/). I am
> > > unable
> > > > > to
> > > > > >>>find a way to determine this information. Any ideas?
> > > > > >>>
> > > > > >>>Thanks.
> > > > > >>>
> > > > > >>>
> > > > > >>>--Marty
> > > > > >>>
> > > > > >>>
> > > > >
> > >
> >>>-
> > > > > >>>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]
> > > > > >>
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Frank W. Zammetti
> > > > > Founder and Chief Software Architect
> > > > > Omnytex Technologies
> > > > > http://www.omnytex.com
> > > > >
> > > > >
> > > > >
> > >
> -
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional comman
Re: PlugIn and the base URL
Do you want the URL or the Internet Protocol address? I have some
ideas on the latter.
Jack
On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner
<[EMAIL PROTECTED]> wrote:
> Jack,
>
> That tells me where the JAR files are stored which is cool. But what I am
> looking for a valid URL (of which there may be many) to access my given
> web application. This info has to come from the container which may be
> the problem. I don't see anything in the container standard which
> provides this info.
>
> Any other ideas?
>
> --Marty
>
> --- Dakota Jack <[EMAIL PROTECTED]> wrote:
>
> > Not sure what you want. Does this help?
> >
> > package whatever;
> >
> > import java.io.File;
> > import java.net.URL;
> >
> > public final class Classpath {
> > public static final String SLASH= File.separator;
> > public static final String HERE =
> > Classpath.class.getClassLoader().getResource("whatever" + SLASH +
> >
> > "Classpath.class").getFile();
> > }
> >
> >
> > On Tue, 25 Jan 2005 19:25:21 -0800 (PST), Martin Wegner
> > <[EMAIL PROTECTED]> wrote:
> > >
> > > As far as I can tell the attributes offer no insight. I have yet to
> > find
> > > a way to get to the container from within a PlugIn. But I will keep
> > > looking. Using an initParam is not an option in this application.
> > >
> > > --Marty
> > >
> > > --- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote:
> > >
> > > > The OP was looking for a way to construct the entire path. I too
> > got as
> > > >
> > > > far as ServletContext, but I'm not sure what in it would give you
> > that,
> > > > or even all the pieces to constuct it... Maybe getAttribute()? I'm
> > not
> > > > sure what it will return, although you can use getAttributeNames()
> > to
> > > > see. The Javadocs indicates the attributes are container-specific
> > > > though, so I'm not sure he'd want to use that anyway.
> > > >
> > > > This is just a matter of curiosity for me at this point, I long ago
> > > > solved this problem another way. I'd like to know how to do it
> > though.
> > > >
> > > > --
> > > > Frank W. Zammetti
> > > > Founder and Chief Software Architect
> > > > Omnytex Technologies
> > > > http://www.omnytex.com
> > > >
> > > >
> > > > Jim Barrows wrote:
> > > > > On Tue, 25 Jan 2005 18:37:29 -0500, Frank W. Zammetti
> > > > > <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > >>I seem to remember trying to solve this problem myself and coming
> > to
> > > > the
> > > > >>conclusion that there was no way to do it independent of a
> > request. I
> > > > >>wound up just sticking it in my application config file that gets
> > read
> > > > >>in the plugin anyway. Can anyone prove me wrong? :)
> > > > >
> > > > >
> > > > > Your looking for the application context correct?
> > > > > In the init you are passed the ActionServlet, which inherits from
> > > > > HttpServlet, which will give you the ServletContext. IIRC you can
> > get
> > > > > the context from there.
> > > > >
> > > > >
> > > > >>--
> > > > >>Frank W. Zammetti
> > > > >>Founder and Chief Software Architect
> > > > >>Omnytex Technologies
> > > > >>http://www.omnytex.com
> > > > >>
> > > > >>Martin Wegner wrote:
> > > > >>
> > > > >>>In have a Struts PlugIn that needs to determine the URL for the
> > > > containing
> > > > >>>web application (http://localhost:8080/BlahBlahBlah/). I am
> > unable
> > > > to
> > > > >>>find a way to determine this information. Any ideas?
> > > > >>>
> > > > >>>Thanks.
> > > > >>>
> > > > >>>
> > > > >>>--Marty
> > > > >>>
> > > > >>>
> > > >
> > >>>-
> > > > >>>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]
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Frank W. Zammetti
> > > > Founder and Chief Software Architect
> > > > Omnytex Technologies
> > > > http://www.omnytex.com
> > > >
> > > >
> > > >
> > -
> > > > 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
Re: PlugIn and the base URL
On Tue, 25 Jan 2005 21:05:30 -0800 (PST), Martin Wegner
<[EMAIL PROTECTED]> wrote:
> Jack,
>
> That tells me where the JAR files are stored which is cool. But what I am
> looking for a valid URL (of which there may be many) to access my given
> web application. This info has to come from the container which may be
> the problem. I don't see anything in the container standard which
> provides this info.
You can calculate what you need from an HttpServletRequest (scheme +
serverName + serverPort + contextPath), but there is no way to
determine this information in a PlugIn's init() method, which is in
turn called from a servlet's init() method.
>
> Any other ideas?
>
> --Marty
>
Craig
> --- Dakota Jack <[EMAIL PROTECTED]> wrote:
>
> > Not sure what you want. Does this help?
> >
> > package whatever;
> >
> > import java.io.File;
> > import java.net.URL;
> >
> > public final class Classpath {
> > public static final String SLASH= File.separator;
> > public static final String HERE =
> > Classpath.class.getClassLoader().getResource("whatever" + SLASH +
> >
> > "Classpath.class").getFile();
> > }
> >
> >
> > On Tue, 25 Jan 2005 19:25:21 -0800 (PST), Martin Wegner
> > <[EMAIL PROTECTED]> wrote:
> > >
> > > As far as I can tell the attributes offer no insight. I have yet to
> > find
> > > a way to get to the container from within a PlugIn. But I will keep
> > > looking. Using an initParam is not an option in this application.
> > >
> > > --Marty
> > >
> > > --- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote:
> > >
> > > > The OP was looking for a way to construct the entire path. I too
> > got as
> > > >
> > > > far as ServletContext, but I'm not sure what in it would give you
> > that,
> > > > or even all the pieces to constuct it... Maybe getAttribute()? I'm
> > not
> > > > sure what it will return, although you can use getAttributeNames()
> > to
> > > > see. The Javadocs indicates the attributes are container-specific
> > > > though, so I'm not sure he'd want to use that anyway.
> > > >
> > > > This is just a matter of curiosity for me at this point, I long ago
> > > > solved this problem another way. I'd like to know how to do it
> > though.
> > > >
> > > > --
> > > > Frank W. Zammetti
> > > > Founder and Chief Software Architect
> > > > Omnytex Technologies
> > > > http://www.omnytex.com
> > > >
> > > >
> > > > Jim Barrows wrote:
> > > > > On Tue, 25 Jan 2005 18:37:29 -0500, Frank W. Zammetti
> > > > > <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > >>I seem to remember trying to solve this problem myself and coming
> > to
> > > > the
> > > > >>conclusion that there was no way to do it independent of a
> > request. I
> > > > >>wound up just sticking it in my application config file that gets
> > read
> > > > >>in the plugin anyway. Can anyone prove me wrong? :)
> > > > >
> > > > >
> > > > > Your looking for the application context correct?
> > > > > In the init you are passed the ActionServlet, which inherits from
> > > > > HttpServlet, which will give you the ServletContext. IIRC you can
> > get
> > > > > the context from there.
> > > > >
> > > > >
> > > > >>--
> > > > >>Frank W. Zammetti
> > > > >>Founder and Chief Software Architect
> > > > >>Omnytex Technologies
> > > > >>http://www.omnytex.com
> > > > >>
> > > > >>Martin Wegner wrote:
> > > > >>
> > > > >>>In have a Struts PlugIn that needs to determine the URL for the
> > > > containing
> > > > >>>web application (http://localhost:8080/BlahBlahBlah/). I am
> > unable
> > > > to
> > > > >>>find a way to determine this information. Any ideas?
> > > > >>>
> > > > >>>Thanks.
> > > > >>>
> > > > >>>
> > > > >>>--Marty
> > > > >>>
> > > > >>>
> > > >
> > >>>-
> > > > >>>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]
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Frank W. Zammetti
> > > > Founder and Chief Software Architect
> > > > Omnytex Technologies
> > > > http://www.omnytex.com
> > > >
> > > >
> > > >
> > -
> > > > 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 i
Re: PlugIn and the base URL
Jack,
That tells me where the JAR files are stored which is cool. But what I am
looking for a valid URL (of which there may be many) to access my given
web application. This info has to come from the container which may be
the problem. I don't see anything in the container standard which
provides this info.
Any other ideas?
--Marty
--- Dakota Jack <[EMAIL PROTECTED]> wrote:
> Not sure what you want. Does this help?
>
> package whatever;
>
> import java.io.File;
> import java.net.URL;
>
> public final class Classpath {
> public static final String SLASH= File.separator;
> public static final String HERE =
> Classpath.class.getClassLoader().getResource("whatever" + SLASH +
>
> "Classpath.class").getFile();
> }
>
>
> On Tue, 25 Jan 2005 19:25:21 -0800 (PST), Martin Wegner
> <[EMAIL PROTECTED]> wrote:
> >
> > As far as I can tell the attributes offer no insight. I have yet to
> find
> > a way to get to the container from within a PlugIn. But I will keep
> > looking. Using an initParam is not an option in this application.
> >
> > --Marty
> >
> > --- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote:
> >
> > > The OP was looking for a way to construct the entire path. I too
> got as
> > >
> > > far as ServletContext, but I'm not sure what in it would give you
> that,
> > > or even all the pieces to constuct it... Maybe getAttribute()? I'm
> not
> > > sure what it will return, although you can use getAttributeNames()
> to
> > > see. The Javadocs indicates the attributes are container-specific
> > > though, so I'm not sure he'd want to use that anyway.
> > >
> > > This is just a matter of curiosity for me at this point, I long ago
> > > solved this problem another way. I'd like to know how to do it
> though.
> > >
> > > --
> > > Frank W. Zammetti
> > > Founder and Chief Software Architect
> > > Omnytex Technologies
> > > http://www.omnytex.com
> > >
> > >
> > > Jim Barrows wrote:
> > > > On Tue, 25 Jan 2005 18:37:29 -0500, Frank W. Zammetti
> > > > <[EMAIL PROTECTED]> wrote:
> > > >
> > > >>I seem to remember trying to solve this problem myself and coming
> to
> > > the
> > > >>conclusion that there was no way to do it independent of a
> request. I
> > > >>wound up just sticking it in my application config file that gets
> read
> > > >>in the plugin anyway. Can anyone prove me wrong? :)
> > > >
> > > >
> > > > Your looking for the application context correct?
> > > > In the init you are passed the ActionServlet, which inherits from
> > > > HttpServlet, which will give you the ServletContext. IIRC you can
> get
> > > > the context from there.
> > > >
> > > >
> > > >>--
> > > >>Frank W. Zammetti
> > > >>Founder and Chief Software Architect
> > > >>Omnytex Technologies
> > > >>http://www.omnytex.com
> > > >>
> > > >>Martin Wegner wrote:
> > > >>
> > > >>>In have a Struts PlugIn that needs to determine the URL for the
> > > containing
> > > >>>web application (http://localhost:8080/BlahBlahBlah/). I am
> unable
> > > to
> > > >>>find a way to determine this information. Any ideas?
> > > >>>
> > > >>>Thanks.
> > > >>>
> > > >>>
> > > >>>--Marty
> > > >>>
> > > >>>
> > >
> >>>-
> > > >>>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]
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > >
> > > --
> > > Frank W. Zammetti
> > > Founder and Chief Software Architect
> > > Omnytex Technologies
> > > http://www.omnytex.com
> > >
> > >
> > >
> -
> > > 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
Re: PlugIn and the base URL
That is actually useful, but I don't think it's what the OP was looking
for... I think he literally wants the complete URL to the current
webapp's root. That's what I was looking for way back when too.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Dakota Jack wrote:
Not sure what you want. Does this help?
package whatever;
import java.io.File;
import java.net.URL;
public final class Classpath {
public static final String SLASH= File.separator;
public static final String HERE =
Classpath.class.getClassLoader().getResource("whatever" + SLASH +
"Classpath.class").getFile();
}
On Tue, 25 Jan 2005 19:25:21 -0800 (PST), Martin Wegner
<[EMAIL PROTECTED]> wrote:
As far as I can tell the attributes offer no insight. I have yet to find
a way to get to the container from within a PlugIn. But I will keep
looking. Using an initParam is not an option in this application.
--Marty
--- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote:
The OP was looking for a way to construct the entire path. I too got as
far as ServletContext, but I'm not sure what in it would give you that,
or even all the pieces to constuct it... Maybe getAttribute()? I'm not
sure what it will return, although you can use getAttributeNames() to
see. The Javadocs indicates the attributes are container-specific
though, so I'm not sure he'd want to use that anyway.
This is just a matter of curiosity for me at this point, I long ago
solved this problem another way. I'd like to know how to do it though.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Jim Barrows wrote:
On Tue, 25 Jan 2005 18:37:29 -0500, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
I seem to remember trying to solve this problem myself and coming to
the
conclusion that there was no way to do it independent of a request. I
wound up just sticking it in my application config file that gets read
in the plugin anyway. Can anyone prove me wrong? :)
Your looking for the application context correct?
In the init you are passed the ActionServlet, which inherits from
HttpServlet, which will give you the ServletContext. IIRC you can get
the context from there.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Martin Wegner wrote:
In have a Struts PlugIn that needs to determine the URL for the
containing
web application (http://localhost:8080/BlahBlahBlah/). I am unable
to
find a way to determine this information. Any ideas?
Thanks.
--Marty
-
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]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
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]
Re: PlugIn and the base URL
Not sure what you want. Does this help?
package whatever;
import java.io.File;
import java.net.URL;
public final class Classpath {
public static final String SLASH= File.separator;
public static final String HERE =
Classpath.class.getClassLoader().getResource("whatever" + SLASH +
"Classpath.class").getFile();
}
On Tue, 25 Jan 2005 19:25:21 -0800 (PST), Martin Wegner
<[EMAIL PROTECTED]> wrote:
>
> As far as I can tell the attributes offer no insight. I have yet to find
> a way to get to the container from within a PlugIn. But I will keep
> looking. Using an initParam is not an option in this application.
>
> --Marty
>
> --- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote:
>
> > The OP was looking for a way to construct the entire path. I too got as
> >
> > far as ServletContext, but I'm not sure what in it would give you that,
> > or even all the pieces to constuct it... Maybe getAttribute()? I'm not
> > sure what it will return, although you can use getAttributeNames() to
> > see. The Javadocs indicates the attributes are container-specific
> > though, so I'm not sure he'd want to use that anyway.
> >
> > This is just a matter of curiosity for me at this point, I long ago
> > solved this problem another way. I'd like to know how to do it though.
> >
> > --
> > Frank W. Zammetti
> > Founder and Chief Software Architect
> > Omnytex Technologies
> > http://www.omnytex.com
> >
> >
> > Jim Barrows wrote:
> > > On Tue, 25 Jan 2005 18:37:29 -0500, Frank W. Zammetti
> > > <[EMAIL PROTECTED]> wrote:
> > >
> > >>I seem to remember trying to solve this problem myself and coming to
> > the
> > >>conclusion that there was no way to do it independent of a request. I
> > >>wound up just sticking it in my application config file that gets read
> > >>in the plugin anyway. Can anyone prove me wrong? :)
> > >
> > >
> > > Your looking for the application context correct?
> > > In the init you are passed the ActionServlet, which inherits from
> > > HttpServlet, which will give you the ServletContext. IIRC you can get
> > > the context from there.
> > >
> > >
> > >>--
> > >>Frank W. Zammetti
> > >>Founder and Chief Software Architect
> > >>Omnytex Technologies
> > >>http://www.omnytex.com
> > >>
> > >>Martin Wegner wrote:
> > >>
> > >>>In have a Struts PlugIn that needs to determine the URL for the
> > containing
> > >>>web application (http://localhost:8080/BlahBlahBlah/). I am unable
> > to
> > >>>find a way to determine this information. Any ideas?
> > >>>
> > >>>Thanks.
> > >>>
> > >>>
> > >>>--Marty
> > >>>
> > >>>
> > >>>-
> > >>>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]
> > >>
> > >>
> > >
> > >
> > >
> >
> > --
> > Frank W. Zammetti
> > Founder and Chief Software Architect
> > Omnytex Technologies
> > http://www.omnytex.com
> >
> >
> > -
> > 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]
Re: PlugIn and the base URL
As far as I can tell the attributes offer no insight. I have yet to find a way to get to the container from within a PlugIn. But I will keep looking. Using an initParam is not an option in this application. --Marty --- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote: > The OP was looking for a way to construct the entire path. I too got as > > far as ServletContext, but I'm not sure what in it would give you that, > or even all the pieces to constuct it... Maybe getAttribute()? I'm not > sure what it will return, although you can use getAttributeNames() to > see. The Javadocs indicates the attributes are container-specific > though, so I'm not sure he'd want to use that anyway. > > This is just a matter of curiosity for me at this point, I long ago > solved this problem another way. I'd like to know how to do it though. > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > > Jim Barrows wrote: > > On Tue, 25 Jan 2005 18:37:29 -0500, Frank W. Zammetti > > <[EMAIL PROTECTED]> wrote: > > > >>I seem to remember trying to solve this problem myself and coming to > the > >>conclusion that there was no way to do it independent of a request. I > >>wound up just sticking it in my application config file that gets read > >>in the plugin anyway. Can anyone prove me wrong? :) > > > > > > Your looking for the application context correct? > > In the init you are passed the ActionServlet, which inherits from > > HttpServlet, which will give you the ServletContext. IIRC you can get > > the context from there. > > > > > >>-- > >>Frank W. Zammetti > >>Founder and Chief Software Architect > >>Omnytex Technologies > >>http://www.omnytex.com > >> > >>Martin Wegner wrote: > >> > >>>In have a Struts PlugIn that needs to determine the URL for the > containing > >>>web application (http://localhost:8080/BlahBlahBlah/). I am unable > to > >>>find a way to determine this information. Any ideas? > >>> > >>>Thanks. > >>> > >>> > >>>--Marty > >>> > >>> > >>>- > >>>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] > >> > >> > > > > > > > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > > - > 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]
Re: PlugIn and the base URL
The OP was looking for a way to construct the entire path. I too got as far as ServletContext, but I'm not sure what in it would give you that, or even all the pieces to constuct it... Maybe getAttribute()? I'm not sure what it will return, although you can use getAttributeNames() to see. The Javadocs indicates the attributes are container-specific though, so I'm not sure he'd want to use that anyway. This is just a matter of curiosity for me at this point, I long ago solved this problem another way. I'd like to know how to do it though. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Jim Barrows wrote: On Tue, 25 Jan 2005 18:37:29 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: I seem to remember trying to solve this problem myself and coming to the conclusion that there was no way to do it independent of a request. I wound up just sticking it in my application config file that gets read in the plugin anyway. Can anyone prove me wrong? :) Your looking for the application context correct? In the init you are passed the ActionServlet, which inherits from HttpServlet, which will give you the ServletContext. IIRC you can get the context from there. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Martin Wegner wrote: In have a Struts PlugIn that needs to determine the URL for the containing web application (http://localhost:8080/BlahBlahBlah/). I am unable to find a way to determine this information. Any ideas? Thanks. --Marty - 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] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PlugIn and the base URL
On Tue, 25 Jan 2005 18:37:29 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > I seem to remember trying to solve this problem myself and coming to the > conclusion that there was no way to do it independent of a request. I > wound up just sticking it in my application config file that gets read > in the plugin anyway. Can anyone prove me wrong? :) Your looking for the application context correct? In the init you are passed the ActionServlet, which inherits from HttpServlet, which will give you the ServletContext. IIRC you can get the context from there. > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > Martin Wegner wrote: > > In have a Struts PlugIn that needs to determine the URL for the containing > > web application (http://localhost:8080/BlahBlahBlah/). I am unable to > > find a way to determine this information. Any ideas? > > > > Thanks. > > > > > > --Marty > > > > > > - > > 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] > > -- James A Barrows - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PlugIn and the base URL
I'm not entirely sure, but I think Struts itself has some code that goes through some length to get information like this. Could be in the Struts ActionServlet object. I don't have time to check right now, though. On Tue, 25 Jan 2005 18:37:29 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > I seem to remember trying to solve this problem myself and coming to the > conclusion that there was no way to do it independent of a request. I > wound up just sticking it in my application config file that gets read > in the plugin anyway. Can anyone prove me wrong? :) > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > Martin Wegner wrote: > > In have a Struts PlugIn that needs to determine the URL for the containing > > web application (http://localhost:8080/BlahBlahBlah/). I am unable to > > find a way to determine this information. Any ideas? > > > > Thanks. > > > > > > --Marty > > > > > > - > > 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]
Re: PlugIn and the base URL
I seem to remember trying to solve this problem myself and coming to the conclusion that there was no way to do it independent of a request. I wound up just sticking it in my application config file that gets read in the plugin anyway. Can anyone prove me wrong? :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Martin Wegner wrote: In have a Struts PlugIn that needs to determine the URL for the containing web application (http://localhost:8080/BlahBlahBlah/). I am unable to find a way to determine this information. Any ideas? Thanks. --Marty - 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]
PlugIn and the base URL
In have a Struts PlugIn that needs to determine the URL for the containing web application (http://localhost:8080/BlahBlahBlah/). I am unable to find a way to determine this information. Any ideas? Thanks. --Marty - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
