On 8/10/2013 11:06 AM, Saurabh Agrawal wrote:
Hi Mark,
You got my problem BANG ON !!
Deploying the /common/* folder under tomcat root is a workaround and I don't
want overhead of installing Apache Server and configure AJP to talk to tomcat.
I copied the /common/* folder inside the following location and it worked-
C:\Users\sagraw\workspace\panera\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\ROOT
In my case it is only one TMP directory which is tmp0 and it doesn't change and
hence my problem is resolved.
Many thanks for your help. I need to do something similar in Netbeans now :)
Regards,
SAURABH AGRAWAL
Manager Technology
—
SapientNitro
-----Original Message-----
From: Mark Eggers [mailto:its_toas...@yahoo.com]
Sent: Saturday, August 10, 2013 9:33 PM
To: Tomcat Users List
Subject: Re: Tomcat 7.0.39 - Embedded Tomcat within Eclipse Juno doesn’t pick
assets from DOC ROOT
Comments inline:
On 8/10/2013 4:29 AM, André Warnier wrote:
Saurabh Agrawal wrote:
Hi,
I have developed Struts 2 application which is deployed on Tomcat. I
am using Eclipse to do the coding and configured Tomcat with Eclipse
to deploy the war from Eclipse itself.
My requirement is that all static assets should be served from Apache
HTTP Server because in our production environment that will be the set
up.
As a result, I have configured image URLS like –
<img src=”/common/images/test.jpg” />
The assumpition is common folder will be the present in the doc root.
I have copied common folder in the ROOT of Tomcat so that it can be
accessed from /common in the URL. However, my images are not getting
picked with the above URL.
I do not pretend to understand your complete setup here, but it looks to
me like you are setting yourself up for a very insecure website layout.
If you are locating resources in Tomcat's webapps/ROOT directory, but
then serving them with Apache HTTPD (and for that, mapping the Tomcat
ROOT folder to make it directly accessible from the HTTPD server), it
means that for *everything* in the Tomcat webapps/ROOT folder your are
completely bypassing the Tomcat bultin security.
(For example, it means that HTTPD users will have direct access to
Tomcat's ROOT/WEB-INF folder files, whatever private information may be
in there.)
HTTPS users will also have access to the source of whatever *.JSP pages
you put there.
Heed the bold text here :
http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html
The point is : by default, Tomcat "knows" that it should not serve
anything from the WEB-INF sub-ditectory, nor serve "raw" JPS's.
But HTTPD does not know that, and by default it will serve these things
without having a second look.
You /can/ make this secure by correct configuration, but it needs
careful work, and it is easy to verlook something.
Hopefully the original poster is just emulating what will be in
production. In other words, rather than having an Apache HTTPD server
with the static files on his development machine, as well as connecting
Apache HTTP and Tomcat with AJP, he's using a shortcut to make sure all
the URLs work.
If not, then yes, security will be a potential issue if you're not
careful. However, if the WAR file containing /common only contains
static material, there may not be much risk.
However, if I create a war file using Maven and deploy it on the
server, /common works. So I think it may be the problem wuth embedded
tomcat instance within eclipse for which may be ROOT is not the doc root.
Can anyone suggest how can it work i.e. deploying application from
eclipse to a configured tomcat instance in eclipse ?
Thanks.
Regards,
SAURABH AGRAWAL
Manager Technology
—
SapientNitro
Aachvis Softech Private Limited SEZ,
“Oxygen”, (Tower C), Ground – 3rd Floor,
Plot No. 7, Sector 144 Expressway,
Noida 201 304, Uttar Pradesh, India
desk +91 (120) 479 5000
mobile +91 981 866 4383
fax +91 (120) 479 5001
Sadly, Eclipse does not work the way you think it does. Eclipse does not
really use CATALINA_HOME/webapps when it deploys applications. It uses
the following:
workspace/.metadata/plugins/org.eclipse.wst.server.core/tmp[n]/wtpwebapps/[context-name]
where [n] is the number of the server you've started up (I think if you
have multiple servers, this depends on which server you start first),
and [context-name] is the context name.
If you look in that directory, you'll see only the applications you've
deployed via Eclipse (no default ROOT application, no examples, no
manager application, nothing).
The cleanest way around this is to deploy everything from within Eclipse.
You could copy the static files to that location, but I don't know if
tmp[n] changes.
You could also set up an Apache HTTPD server, copy the files there, and
link the two with AJP. While that sounds a bit more complicated, it's
not really that difficult. This would have the advantage of more closely
emulating the production environment as well.
. . . . just my two cents.
/mde/
I like Neven's solution much better (run an Apache web server, and let
Eclipse manage your Tomcat installation). I'm a NetBeans person, so my
major experience with Eclipse is answering questions for people that I
work with.
NetBeans just manages the existing Tomcat. You can drop your static
files into CATALINA_HOME/webapps and happily run.
Another option that NetBeans has is that it will let you use is a
private Tomcat installation based on CATALINA_BASE. Read RUNNING.txt in
any standard Tomcat release to get that set up.
The CATALINA_BASE solution sounds very much like Neven's solution #3,
but I'm not sure if it would follow the Tomcat way of doing things
(haven't tried this yet).
On my machines, I do the following:
1. Use Apache HTTP / AJP - mod_jk
2. Map the appropriate URLs in uriworkermap.properties
This file gets scanned once per minute by default
Nice for development / testing
3. Control Tomcat with NetBeans - sometimes use startup scripts
4. Browse to port 80 to test collections of web applications
5. Browse to port 8080 (and run Tomcat in debug mode) for debugging
I'm sure if you select solution 2 from Neven's list, you could set up
something similar in Eclipse.
The only thing in Eclipse that you have to be careful of is using some
plugins with Maven. The Maven-WTP integration doesn't catch all of the
changes that some plugins make, meaning that you won't get the latest
version of the web application displaying in Tomcat.
I ran into the integration issue when using a Javascript / CSS
compression plugin. It's annoying, but I think you can get around it by
refreshing your project after a build.
As another alternative, you could try using the Maven Tomcat plugin. I
had pretty good luck with the Maven Jetty plugin, so I imagine things
would work in a similar fashion.
. . . . just my two cents.
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
