This week's book giveaway is in the JavaScript forum.
We're giving away four copies of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js and have Paul Jensen on-line!
See this thread for details.
Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

TomEE Servlet+Connector+Webapp issue  RSS feed

 
Richie Ju
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys,

i need your help. I want to use a Custom Servlet , a Connector for HTTPS, and a Webapp twice in tomcat EE.

Problem: Tomcat EE disable others like "addServlet" | "Connector " if i use "addWebapp" or the other way round.
Some way to fix this?

Here is a code snipped




Thanks a lot for answers
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the JavaRanch, Richie!

I don't understand the question, but perhaps some explanations will help.

First, Connectors are not attached to specific servlets. A Connector defines a TCP/IP port that a given Host or Engine will listen to for network requests (HTTP, HTTPS, ajp, or whatever, depending on the connector). Once a URL request comes in to that Connector, Tomcat will parse it and locate the webapp that it should be routed to, then dispatch the request to that webapp.

Second, servlets do not stand alone. A servlet is part of a webapp. A webapp is deployed in WAR format (either zipped or exploded) under a defined webapp context path, which is what Tomcat looks for when it parses a URL request. So the addServlet method expects to find a webapp that has already been deployed and add that servlet to the webapp. In almost all cases, that is a bad thing to do. It's better that the servlet have been already packaged as part of the WAR. The primary purpose of addServlet is as part of Tomcat's own internal deployment logic, I think.

Here is an abbreviated sketch of how the Tomcat beans are assembled

Hosts contain 1 or more webapps, each with a context path associated with a WAR. You can deploy the same WAR more than once, but in order for it to run as independent webapps, each WAR reference would require a distinct context path to be deployed under.
 
Richie Ju
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hey first thanks tim for good explanation.

i have to use a Tomcat Embedded server, the connector part is fixed yet its running i forgot only the "s" on https to test it.

Second, servlets do not stand alone. A servlet is part of a webapp. A webapp is deployed in WAR format (either zipped or exploded) under a defined webapp context path, which is what Tomcat looks for when it parses a URL request.


First i don't have any wars or server.xml or web.xml.
I used tomcatt ee and hardcoded xml structure in java.

So the addServlet method expects to find a webapp that has already been deployed and add that servlet to the webapp. In almost all cases, that is a bad thing to do.

thanks glad to hear that

Now i 'm unterstood tomcat a little better.

Still can you tell me how I add a Servlet to the standard webapp with tomcat.addwebapp command?
(Goal: for example: run a index.html site & Servlet twice )

Kindly regards Richie
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It doesn't matter if it's Tomcat, Tomcat EE, or WebSphere. J2EE webapp containers run webapps. No exceptions. Servlets belong to webapps. No exceptions.

The server.xml file is simply a configuration file that the catalina application program uses to configure a Tomcat server. It reads the file in and digests it using the Apache Digester, which then results in a customized Tomcat server. It's effectively doing the same thing that you are doing except that instead of hard-coded program logic, it's using a static definition.

The web.xml file is likewise digested as part of deploying a web application to produce the webapp's internal context definition objects. These days you can sometimes omit the actual file and one will be synthesized from defaults and annotations, but the structures are still there and still associated with a context path.

When you use the Tomcat addwebapp method, you are merely doing what the standard Tomcat deployer does when it constructs or digests a webapp Context. You define a context path and a codebase. The codebase is the location of the webapp's resources - servlets, JSP sources, static files such as javascript, CSS, images, and so forth.

There is no "standard" or "default" webapp as such. There is a default servlet, but Tomcat automatically and invisibly adds it to every deployed webapp as shared code. The default servlet is what produces an index listing if you reference a directory resource instead of a file or servlet resource, it's what renders static resources as responses back to the client, and it's what constructs and sends the "404 not found page" if a resource cannot be found. It gets invoked whenever a resource path cannot be matched against the servlet path maps in web.xml.

I've never checked to see exactly what happens in Tomcat when you send a request to an Host where the context path doesn't match. It's possible that Tomcat may have constructed an internal webapp to generate the "404" page that comes back where the webapp has effectively only the default servlet in it, but even if it does, you should NOT hack that to do things that any ordinary J2EE-compliant web application can do. Because what you'd produce would not only fail to comply with J2EE and JEE standards, it could very well cease to operate properly when Tomcat changes. The difference between being clever and being "clever" is knowing how to exploit internals but also knowing how to avoid having to do so.

If you are just looking for a system where you can package a Tomcat server and pre-defined webapp(s) as a ready-to-run unit, you might want to look at Spring Boot. It's designed for exactly that purpose.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!