how to send data to a pre configured servlet

[Dundonald]

Is it possible to configure a java web app running under a context
root to automatically take data from a URL (entered after the context
root) and pass that data as a paramater to a specific servlet?

For example -

I have a domain called "test.com" and a java web app running under the
context root "myroot" and I want to pass data "hello_world" to servlet
PrintMessageServlet without the user ever having to worry about
entering the servlet in the URL. So user types in ...

www.test.com/myroot/hello_world

PrintMessageServlet would only ever expect one paramater to be passed
in, and the data for that paramater would be whatever is entered after
www.test.com/myroot/

Does this make sense?

If so please can you advise me how I can achieve this by configuring
my web. I run this web app under apache and tomcat on my web host.

Thanks

 

[Donkey Hot]

Is it possible to configure a java web app running under a context
root to automatically take data from a URL (entered after the context
root) and pass that data as a paramater to a specific servlet?

For example -

I have a domain called "test.com" and a java web app running under the
context root "myroot" and I want to pass data "hello_world" to servlet
PrintMessageServlet without the user ever having to worry about
entering the servlet in the URL. So user types in ...

www.test.com/myroot/hello_world

PrintMessageServlet would only ever expect one paramater to be passed
in, and the data for that paramater would be whatever is entered after
www.test.com/myroot/

Does this make sense?

If so please can you advise me how I can achieve this by configuring
my web. I run this web app under apache and tomcat on my web host.

Thanks

Does not work. The servlet container tries to find a servlet with context
root /myroot/hello_word, and your myroot servlet never gets a call.

 

[Dundonald]

(e-mail address removed):









Does not work. The servlet container tries to find a servlet with context
root /myroot/hello_word, and your myroot servlet never gets a call.

I'm really surprised if this isn't possible. Take for example common
services such as tinyurl.com and use of search a service by using a
URL such as http://tinyurl.com/6 (in this case the functionality is
to redirect to another page).

 

[Mark Space]

Is it possible to configure a java web app running under a context
root to automatically take data from a URL (entered after the context
root) and pass that data as a paramater to a specific servlet?

For example -

I have a domain called "test.com" and a java web app running under the
context root "myroot" and I want to pass data "hello_world" to servlet
PrintMessageServlet without the user ever having to worry about
entering the servlet in the URL. So user types in ...

www.test.com/myroot/hello_world

PrintMessageServlet would only ever expect one paramater to be passed
in, and the data for that paramater would be whatever is entered after
www.test.com/myroot/

It seems like you could do this just by setting the deployment
descriptor correctly. Given the info above, just set the deployment to
send everything to PrintMessageServlet. If you have other servlets,
parse those first, then send anything that remains to the print servlet.

If the processing is too complicated for that, you could employ a filter
to re-write the URL so that it could be processed by a deployment
descriptor. Or send everything to one big all encompassing servlet,
where you decide (programactically, using Java) which other servlets to
dispatch to, including the print message one.

I guess it might help if we had a bit more info. What methods have you
tried to configure this so far, and what problems did you run into?
That'll help us suggest a plan for further experimentation.

 

[Dundonald]

It seems like you could do this just by setting the deployment
descriptor correctly. Given the info above, just set the deployment to
send everything to PrintMessageServlet. If you have other servlets,
parse those first, then send anything that remains to the print servlet.

If the processing is too complicated for that, you could employ a filter
to re-write the URL so that it could be processed by a deployment
descriptor. Or send everything to one big all encompassing servlet,
where you decide (programactically, using Java) which other servlets to
dispatch to, including the print message one.

I guess it might help if we had a bit more info. What methods have you
tried to configure this so far, and what problems did you run into?
That'll help us suggest a plan for further experimentation.

Haven't coded anything yet, just thinking about the plan of attack at
the moment. But now we're thinking ...

How about setting a default JSP or servlet to be served for that
context root. BUT, how do you prevent a 404 being returned for URL
such as

www.test.com/myroot/hello_world

so that a resource called "hello_world" is not looked up for and
instead that info is passed to the default page / servlet?

 

[Mark Space]

How about setting a default JSP or servlet to be served for that
context root. BUT, how do you prevent a 404 being returned for URL
such as

www.test.com/myroot/hello_world

I read your other response about wanting this to work like tiny url.
Just set all paths for your web app to go to your one servlet. If you
use a splat ("*") for the url path, it will match anything, and it will
be redirected. That's how you prevent 404 errors (or how you handle
them manually, if you wish to do so programatically).

Look up deployment descriptors for servlets, especially the
<servlet-mapping> tag. These all go in the web.xml file btw, look up
the syntax for that too.

 

[Dundonald]

Dundonaldwrote:


I read your other response about wanting this to work like tiny url.
Just set all paths for your web app to go to your one servlet. If you
use a splat ("*") for the url path, it will match anything, and it will
be redirected. That's how you prevent 404 errors (or how you handle
them manually, if you wish to do so programatically).

How is the "hello_world" data pulled in from the servlet, because
there is nothing like

resource?param=data

Look up deployment descriptors for servlets, especially the
<servlet-mapping> tag. These all go in the web.xml file btw, look up
the syntax for that too.

Yes I use servlet mapping currently for example

<servlet-mapping>
<servlet-name>MyServlet</servlet-name>
<url-pattern>/MyServlet</url-pattern>
</servlet-mapping>

So if I use the splat ("*") you mean something like:

<servlet-mapping>
<servlet-name>CatchAllServlet</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>

?

And if I had such as the above can I still use all my other servlet
mappings?

 

[Mark Space]

So if I use the splat ("*") you mean something like:

<servlet-mapping>
<servlet-name>CatchAllServlet</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>

?

And if I had such as the above can I still use all my other servlet
mappings?

As I understand it, yes. This is why I say to look stuff up, since
these details are easy to find. I don't deal with setting the
url-patterns myself usually, and I can't know everything that you might
want to do with your applications, so it's good for you to know how this
works so that you can plan.

Explicitly for <url-pattern> the matching goes like this (I think):

1. Any exact match without a wildcard is taken first. A pattern like
/hello_world would always match a path of <context>/hello_world.

2. Then the longest possible match is taken that ends in a wildcard. So
a pattern of /hello* would match <context>/hello_world before /h* would.

3. Then any matches that begin with a wildcard are taken. A url-pattern
of *.do would be matched last after all of the above patterns,
regardless of length. I don't know if there's a tie breaker for
extensions like there is for 2. above. I don't think so.

4. Finally, if nothing else matches, /* is matched if present. It's a
catch-all.

This is in O'Reilly's _Learning Java_ btw. But there are better books
for web apps. You should definitely get some kind of primmer or
reference, wildcard matching in <url-pattern> is pretty basic stuff.

 

[Dundonald]

Dundonaldwrote:

As I understand it, yes. This is why I say to look stuff up, since
these details are easy to find. I don't deal with setting the
url-patterns myself usually, and I can't know everything that you might
want to do with your applications, so it's good for you to know how this
works so that you can plan.

Explicitly for <url-pattern> the matching goes like this (I think):

1. Any exact match without a wildcard is taken first. A pattern like
/hello_world would always match a path of <context>/hello_world.

2. Then the longest possible match is taken that ends in a wildcard. So
a pattern of /hello* would match <context>/hello_world before /h* would.

3. Then any matches that begin with a wildcard are taken. A url-pattern
of *.do would be matched last after all of the above patterns,
regardless of length. I don't know if there's a tie breaker for
extensions like there is for 2. above. I don't think so.

4. Finally, if nothing else matches, /* is matched if present. It's a
catch-all.

This is in O'Reilly's _Learning Java_ btw. But there are better books
for web apps. You should definitely get some kind of primmer or
reference, wildcard matching in <url-pattern> is pretty basic stuff.

Thanks Mark.