Re: Question regarding tomcat class path handling
On Mon, Jan 09, 2006 at 08:16:00PM +0200, Oded Arbel wrote:
The problem is like this (the actual system is far more complex):
- suppose two web applications, app1 and app2, both use some API (which
I developed myself).
- I don't want to develop the API twice on both web applications, so I
have a third project for the API itself, which is a not a web
application and so isn't in WEB-INF/classes of neither app1 nor app2.
- I don't want to build a jar for that API library to put in app1 and
app2's WEB-INF/lib because its also constantly being developed - if I
wanted to do this then after each commit, in addition to the build
stage I would have to copy the jar by hand to all the applications that
use it, which is an error prone process.
You've got to be kidding. Copy by hand!? Why? Just build the jar
file to some predefined location, and have the build process for each app
copy it from there. There's no need to copy it by hand, have ant, or whatever
you're using to build, do it for you.
That seems much simpler than playing with custom class loaders, or
startup classpath dependencies, or loose class files.
e.g. say you've got 4 different api's. When you build those, a jar file
gets created in (e.g.) /myjars:
/myjars/api1.jar
/myjars/api2.jar
/myjars/api3.jar
/myjars/api4.jar
Let's say app1 uses api's 1, 3 and 4, so it has something like this
somewhere in its build.xml: (assuming you're using ant)
copy file=/myjars/api1.jar todir=${WEB_DIR_LOCATION}/lib/
copy file=/myjars/api3.jar todir=${WEB_DIR_LOCATION}/lib/
copy file=/myjars/api4.jar todir=${WEB_DIR_LOCATION}/lib/
and app2 uses 2 and 4, so it instead has:
copy file=/myjars/api2.jar todir=${WEB_DIR_LOCATION}/lib/
copy file=/myjars/api4.jar todir=${WEB_DIR_LOCATION}/lib/
etc...
of course, if you don't want a global location for the api jar files,
you can always use a relative path. This is what I do in my app. I've
got a directory structure that looks like this:
mycode/
myapi/
build.xml (builds the java files and creates myapi.jar)
build/myapi.jar
myapp/
build.xml (copies ../myapi/build/myapi.jar to build/WEB-INF/lib e.g.:
copy file=../../myapi/build/api1.jar
todir=${WEB_DIR_LOCATION}/lib/
build/WEB-INF/lib/myapi.jar
eric
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import doesn't work right with HEAD requests
Hassan Schroeder [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] No. But I wouldn't have *any* expectations of an ambiguous situation. Out of curiousity, have you tried this with any different containers (Jetty, Resin, JRun, ...)? no, I haven't. I think I've got a websphere instance I can get to. I'll try it there. That might have a different implementation of the core taglibs even . On Sun, Dec 18, 2005 at 05:08:54PM -0800, Bill Barker wrote: From http://issues.apache.org/bugzilla/show_bug.cgi?id=37466, it looks like it's a waste of time checking other containers. It seems that this is a known bug at least in the Jakarta implementation of JSTL. known? ha! I submitted that, and judging by the response I got when asking about this problem on the taglibs list, I wouldn't be surprised if you're the first other person to see that bug. :-| eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: c:import doesn't work right with HEAD requests
On Sun, Dec 18, 2005 at 09:06:22AM -0500, Martin Gainty wrote: Did you include the core taglib spec before using 'c' reference identifier %@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; % Of course. It's the very first line in testit.jsp. w/o that it wouldn't work even for GET requests. What does the Tomcat log say about this? The only output in the log is what I wrote there with System.out.println. eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
c:import doesn't work right with HEAD requests
I'm having some trouble getting the c:import tag to work right.
It seems to be perfectly fine when the request that tomcat receives is
a GET request. However, when it receives a HEAD request instead, c:import
never actually reads the data.
Is this a known bug? Is it fixed in a more recent version of tomcat?
I'm using 5.0.30.
eric
Here's an example jsp file testit.jsp:
---cut---
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
c:import url=/testit.txt var=foo/
%
System.out.println(FOO:[ + pageContext.getAttribute(foo) + ]);
%
worked: ${foo}
---cut---
Here's testit.txt:
---cut---
data data data
---cut---
When I send a GET request to retrieve /myapp/testit.jsp, I get the expected
worked: data data data in the response, and in catalina.out I get:
---cut---
FOO:[data data data
]
---cut---
That's what I expect. However, if I send a HEAD request I get no output
other than headers in the response (as I expect), but catalina.out has
this instead:
---cut---
FOO:[]
---cut---
Notice there's nothing inside the [].
Here's my HEAD request transcript:
poe: {50} telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD /myapp/testit.jsp HTTP/1.1
Host: localhost:8080
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=5A2DA89DDC03A24F4CF110EFD1BB6541; Path=/myapp
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 15
Date: Sun, 18 Dec 2005 05:29:54 GMT
Server: Apache-Coyote/1.1
^]
telnet c
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Singleton memory leak after redeploying.
On Mon, Nov 28, 2005 at 06:24:52PM +0100, Lionel Farbos wrote: Hi Juan, I think your problem can't be solved (only) by Tomcat. The problem is that objets stay in memory because of pointers on static references... but aren't those supposed to go away when the classloader is no longer referenced? If you can't get to the classloader that loaded the class then you can't get to the static fields, so it should be gc'd. no? eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: manager for some users
On 11/22/05, Kyle [EMAIL PROTECTED] wrote: If you set which ever server.xml parameter it is that auto-reloads an application (I think it's reloadable=true, or something like that) and just have your users recompile their entire app each time and then ftp it into the relevant directory, tomcat should automatically reload each app for them without anyone needing manager access. On Tue, Nov 22, 2005 at 01:17:56PM +0100, Alex Moreno wrote: The problem is that some partners has said me that this is insecure and should only be used on beta application servers. At least this is what the department says us to deny this petition. what? They say ftp is insecure? Well horray for inept admins who don't know how to configure their system. Or are they claming that reloadable is insecure? uh, so if you can't use the manager, and you can't put files where tomcat can get at them, how DO you install a webapp? The problem is that the department don?t want to give us manager access for all the applications. I?ve been looking for the way of giving manager access to only one or two application, depending on the user. What you probably want is different instances of tomcat for each user. Otherwise it is trivial for one person's webabb to bring down everyone elses. e.g. sometimes all it takes is re-installing the webapp enough times until tomcat runs out of memory. eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
