Re: Question regarding tomcat class path handling

2006-01-12 Thread erh
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

2005-12-20 Thread erh
 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

2005-12-18 Thread erh
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

2005-12-17 Thread erh

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.

2005-11-28 Thread erh
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

2005-11-22 Thread erh
 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]