Summary: | System for handling webapps; compilation and runtime env vars | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tiago Freire <tiago.freire> |
Component: | Current packages | Assignee: | Java team <java> |
Status: | RESOLVED REMIND | ||
Severity: | enhancement | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Tiago Freire
2004-04-14 14:09:49 UTC
This seems normal to me. Typically when creating servlets, you need to include the servlet-api.jar in the compile classpath (in the environment if you are using javac from the command line, or through build.xml if you are using ant). One of the ways to include it in the environment (so that it always happens) is: emerge servletapi then, if you want the servlet api to be in classpath for all users, run: java-config -B servletapi-2.4 of if you want it for just you: java-config -b servletapi-2.4 and follow the instructions from java-config. This bug scratches the surface on a rather complex problem. There are multiple servlet providers. You should not need to have tomcat installed to compile against the servletapi, just installing the servletapi should suffice. However, once you have tomcat installed, and given that no other servletapi provider was present, you'd expect tomcat to provide it for you. This has been discussed a bit, but nobody has found the time to implement it properly. The currently envisioned solution is to create virtual/servletapi, and have the servlet containers PROVIDE this. One should be able to do java-config -b servleapi-<interface version>, where interface version is the version of the servletapi interface you're requesting. This part is a bit more tricky, as java-config does not currently understand virtuals. Additionally, we will most likely be removing the env var file from tomcat, to ensure proper operation in the face of users inadvertently experimenting with their env vars. Talked to Stu in the webapps herd. They are not considering Java webapps at the moment, so this task is squarely on our shoulders. We should gang up on this this problem and come up with a semi-decent solution that plays nice with the existing webapps infrastructure (webapp-config, webapp.eclass). Unfortunately, we don't currently have the manpower to develop and maintain such a system. I hope we will be able to in the future though, so I'm going to resolve this with REMIND, so we can come back to it. |