Re: Question about tomcat startup ConcurrentModificationException

2005-09-28 Thread Maurice Yarrow

Hello Jilles

So I have downloaded the mx4j-2.1.1.tar and untarred it,
but since there is no exact match for jmx.jar in the mx4j distribution
I zipinfo'd and sorted:
the original   tomcat/bin/jmx.tar (235 classes)
   mx4j.jar   (285 classes)

When diff'd, mostly a good match, but a couple of classes that are
in jmx.jar are missing from mx4j.jar.  I presume these are classes
req'd by others in the package but are not called directly by tomcat.

So you are suggesting that I replace the tomcat/bin/jmx.jar
with the mx4j.jar ?

If so, then I have a stupid question:  when I do this replacement,
should I rename the mx4j.jar to jmx.jar ?


Maurice


Jilles van Gurp wrote:
The fix is to replace the mx4j jar file in the release (bin/jmx.jar) 
with the fixed version (latest 2.1.x) which has been available for a 
long time now from the mx4j project site.


You might also search this mailinglist. This must be one of the more 
frequently raised topics. I know I found the right answer here half a 
year ago or so.


I'd really appreciate a stable 5.0.x release with the fix. I've known 
about this bug for more than half a year now and I still encounter it at 
least once a week at customers. I then need to explain that it is not 
our product that is broken but tomcat and that it's a well known issue 
and it is easy to fix. Basically all our customers run into this issue.


Lets face it, 5.0.28 is basically broken because of this easy to fix 
bug. People claim it rarely occurs (and consequently that it is 
perfectly acceptable to occasionally fail to launch with an obscure 
exception). Yet, I can't launch my webapp on an unpatched tomcat 5.0.28 
unless I fix this first. Sometimes I forget on a clean install and then 
seconds later slap my forward. Just do a 5.0.28_01 with the fixed jar or 
finally move 5.0.30 to a stable release (I can't convince customers to 
install beta software) but please fix it one way or the other.


Jilles

Tim Funk wrote:

Search bugzilla.  There is a bug report about 
ConcurrentModificationException - it has to do with mx4j having a race 
condition. The bug describes a fix.


-Tim

Maurice Yarrow wrote:


Hello Tomcat people

When tomcat is restarted, it occasionally (1 in 25 times)
gets the below exception.  (tomcat 5.0.28, on Fedora Core 1)

What is the significance of this?

Thanks
Maurice


INFO: Starting Coyote HTTP/1.1 on http-8080
Sep 26, 2005 9:29:19 AM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8443
Sep 26, 2005 9:29:19 AM org.apache.coyote.tomcat5.MapperListener init
WARNING: Error registering contexts
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782)
at java.util.HashMap$EntryIterator.next(HashMap.java:824)
at java.util.HashMap.putAllForCreate(HashMap.java:424)
at java.util.HashMap.clone(HashMap.java:656)
at 
mx4j.server.DefaultMBeanRepository.clone(DefaultMBeanRepository.java:56)
at 
mx4j.server.MBeanServerImpl.findMBeansByPattern(MBeanServerImpl.java:160 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Synchronize wrapper for session obj attrib get/set

2005-09-26 Thread Maurice Yarrow

Leon, Chuck:

Thankyou very much for (1) pointing out that tomcat has internal
session obj accesses, so go with something that accomplishes a
global fix and (2) just as important: what the current patches
are for 5.0.19+.

Leon, I went with your pre-compiled StandardSession.class and
replaced the original one in the catalina.jar and am up and running.

Thanks again, gentlemen.

Maurice Yarrow



Leon Rosenberg wrote:

Possibly the easiest thing to do is edit the StandardSession.java file
and change the type of the attributes field to HashTable rather than
HashMap, then rebuild the associated jar.  The places that already
synchronize on attributes can be left alone, since redundant synchs are
allowed and have minimal performance impact.

- Chuck



Or, you take one of existing patches, see also:
http://www.niallp.pwp.blueyonder.co.uk/TomcatBug36541.html

or, you just get the last StandartSession version out of CVS ( sorry
SVN since this weekend) ,
and compile it.

regards
Leon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Question about tomcat startup ConcurrentModificationException

2005-09-26 Thread Maurice Yarrow

Hello Tomcat people

When tomcat is restarted, it occasionally (1 in 25 times)
gets the below exception.  (tomcat 5.0.28, on Fedora Core 1)

What is the significance of this?

Thanks
Maurice


INFO: Starting Coyote HTTP/1.1 on http-8080
Sep 26, 2005 9:29:19 AM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8443
Sep 26, 2005 9:29:19 AM org.apache.coyote.tomcat5.MapperListener init
WARNING: Error registering contexts
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782)
at java.util.HashMap$EntryIterator.next(HashMap.java:824)
at java.util.HashMap.putAllForCreate(HashMap.java:424)
at java.util.HashMap.clone(HashMap.java:656)
at 
mx4j.server.DefaultMBeanRepository.clone(DefaultMBeanRepository.java:56)
at 
mx4j.server.MBeanServerImpl.findMBeansByPattern(MBeanServerImpl.java:1603)
at 
mx4j.server.MBeanServerImpl.queryObjectNames(MBeanServerImpl.java:1568)
at 
mx4j.server.MBeanServerImpl.queryMBeans(MBeanServerImpl.java:1512)
at 
org.apache.coyote.tomcat5.MapperListener.init(MapperListener.java:115)
at 
org.apache.coyote.tomcat5.CoyoteConnector.start(CoyoteConnector.java:1537)
at 
org.apache.catalina.core.StandardService.start(StandardService.java:489)
at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:2313)

at org.apache.catalina.startup.Catalina.start(Catalina.java:556)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:287)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Synchronize wrapper for session obj attrib get/set

2005-09-25 Thread Maurice Yarrow

Hello Tomcat people

For those not wishing to migrate at this time to 5.5.12
(in our case, from 5.0.28 and jdk 1.4) would the following
be sufficient for preventing deadlock access of the session
objects ?

In a given servlet, say, ServletA, for example, might have:

HttpSession session = getSessionCheckValid( request );

synchronized( session )  {
session.setAttribute( particularAttribName,
  particularAttribVal );
}

The question arises, if this session obj is being used from
a variety of such servlets, does the above code in ServletA
prevent simultaneous access to the set method of the same obj
in a similar synchronized block in some other servlet, say,
in ServletB ?

If, on the other hand, one chooses to write a class extending
the HttpSession interface, and then (2) wrap the get/set and other 
applicable methods with synchonized methods, then what is the

minimum amount of threading machinery that must to be provided
(i.e., Runnable, run(), etc) to accomplish this wrapping ?

For that matter, has someone done this who would be willing
to share such code ?


Maurice Yarrow


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: How to share static content across applications

2005-09-15 Thread Maurice Yarrow

Hello Tim

Saw your posting on the tomcat user's list.
I have a question about your response:

So how do you access the static resources, i.e.,
images, from the other two web apps?

This is what I tried and it does not work:

I created a separate webapp context with images,
and placed into tomcat/conf/Catalina/localhost
a Context... element that looks like this:

   Context path=/img
docBase=img
debug=0
reloadable=true
allowLinking=true /
   /Context

and in webapps/img I

   ln -s /usr/scratch/images images

to create the symlink.  So far, so good
Then, for the web app which needed the images,
I created this Context... element:

   Context path=/getimg
docBase=getimg
debug=0
reloadable=true
crossContext=true
   /Context

Then from one of the servlets in getimg, I tried to

try {
RequestDispatcher dispatcher = 
getServletContext().getContext(/img).getRequestDispatcher(/images+request.getPathInfo());

dispatcher.include(request, response);
 } catch(Exception ex) {
ex.printStackTrace();
 }

and to invoke as getimg/ImageServlet/subPath...
but nothing happened, and in fact, the

getServletContext().getContext(/img) returned null.

Note that the thusly constructed path to the image is
in fact correct.  This was not an issue of Not Found.


Thanks

Maurice Yarrow








 I typically create a 3rd webapp with those shared images and other
 similar assets.

 Otherwise - you can import those shared assets into your webapp at
 build time by placing all the shared assets into their own version
 control repository.

 -Tim


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: no luck with allowLinking=true

2005-09-12 Thread Maurice Yarrow

Hassan

Thank you for thinking about this and suggesting
the context fragment that you have successfully used.

I had tried such a fragment a little while back,
without success, but tried it again just now
exactly as you had indicated.  I tried placing it
in

tomcat/conf/Catalina/localhost/getimg.xml

and I also, separately, tried placing that Context
element in the Host element of server.xml.

Neither configuration worked to allow symlinks.

Note: I know that the Context element works for
me in the more broad usage of deploying a webapp
in an arbitrary location:  I just (again) tried

Context path=/getimg
 docBase=/tmp/GetImgExperiment/getimg
 ...

and, after deleting from webapps directory the
existing getimg deployment and getimg.war, I
restarted tomcat.  And, of course, the getimg
app worked fine.  But adding the allowLinking=true,
either as you had indicated, or as I had been doing,
(and creating a ln -s /usr/scratch/images images)
accomplished nothing.  There was no visibility.
Note that from the command line, from tomcat, I
certainly can

ls webapp location/getimg/images

and see the contents of that directory once the
symlink is created.  It's just that the getimg
app itself still cannot see it.  And, as I
previously indicated, actually creating a
directory in the webapp tree with images
in it of course makes those images visible
to the app.

Thanks again for the suggestion.

Frankly, I'm as confounded as you about this.
As I indicated in my first letter, I always find
(eventually) the correct configuration for just
about anything that is required, but this has
eluded me.  There must be some conflict which I
am not seeing, but, pretty much, my tomcat
configuration is fairly vanilla: have postgres,
am using OpenEJB as well as JDBC, all successfully.
Use lots of XStream xml files for app information,
but none of this should be a conflict.  Hmmm, let's
see: am also using the SSL/https Connector in
the conf/server.xml, and have enabled CGI from
the conf/web.xml, and all this works fine for me.

Also, as I indicated in my first letter, I even
set up a completely new 5.0.30 complete deployment
to test this issue, but the results were the same.

Puzzled, in Sunnyvale,

Maurice


Hassan Schroeder wrote:

Maurice Yarrow wrote:

I have simply had no success getting allowLinking=true.  


/

Am running 5.0.28  (tried it in 5.0.30, as well, with same lack of 
success).


/


Context path=/getimg
 docBase=getimg
 debug=0
 reloadable=true
 crossContext=true
Resources className=org.apache.naming.resources.FileDirContext
   allowLinking=true /
/Context



Shouldn't that just be:

Context path=/getimg
 docBase=getimg
 debug=0
 reloadable=true
 crossContext=true
 allowLinking=true
/Context

:: ? which works for me in TC 5.5.x, at least, and appears to match
the Context attribute descriptions for 5.0.x in
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/context.html

FWIW!




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: no luck with allowLinking=true

2005-09-12 Thread Maurice Yarrow

Hello Hassan

Thanks again:
however:
(1) tomcat is started by root who superusers tomcat process
to be owned by user tomcat, as you can see from ps:

 1415 tomcat /opt/j2sdk1.4.2_05/bin/java
-Djava.endorsed.dirs=/opt/tomcat/comm,etc...

(2) Tomcat owns the link:

lrwxrwxrwx  1 tomcat tomcat 32 Sep 12 11:32 images -
 /usr/scratch/images

so tomcat certainly owns the link, but also:

(3)  Tomcat can write to and read from the linked dir directly:

[EMAIL PROTECTED] webapps]$ ls -ld /usr/scratch/images
drwxrwxr-x  2 tomcat tomcat 4096 Sep 12 11:44 /usr/scratch/images

[EMAIL PROTECTED] webapps]$ echo hello  /usr/scratch/images/hello.dat
(i.e., user tomcat has no problem creating only images dir)

and

[EMAIL PROTECTED] webapps]$ cat /usr/scratch/images/hello.dat
hello
(i.e., user tomcat has no problem seeing the file)

and
(4) also, tomcat can even delete the file via the link
 (no error, and file is removed)

Maurice



Hassan Schroeder wrote:

Maurice Yarrow wrote:



Neither configuration worked to allow symlinks.




Also, as I indicated in my first letter, I even
set up a completely new 5.0.30 complete deployment
to test this issue, but the results were the same.



That's good, eliminating as many variables as possible. And if that
setup doesn't work...

Is it possible you have a permissions problem between the Tomcat
process userid and the owner of the linked directory?





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



no luck with allowLinking=true

2005-09-11 Thread Maurice Yarrow

Hello tomcat-users

I have simply had no success getting allowLinking=true.  I have read
simply dozens and dozens of links with a standard recipe for doing this,
as well as the tomcat documentation, of course.

Am running 5.0.28  (tried it in 5.0.30, as well, with same lack of success).

I have tried placing the context fragment (which, as a separate file,
I call getimg.xml) in virtually every place I could think of, as well as
the recommended locations:

tomcat/conf/Catalina/localhost/getimg.xml

In the server.xml host element (at the bottom of the element)

In the webapps directory...

This is the context fragment I am using:

Context path=/getimg
 docBase=getimg
 debug=0
 reloadable=true
 crossContext=true
Resources className=org.apache.naming.resources.FileDirContext
   allowLinking=true /
/Context

I then place the following symbolic link in the webapps/getimg
directory:

ln -s /usr/scratch/images images

and reboot tomcat.  But, no visibility whatsoever!  Of course,
when I actually mkdir a directory in webapps/getimg, files in
this directory are visible, but not with a symlink, and of course
I don't want to have to actually put gigabytes of stuff in the
tomcat tree.  I have, however, successfully used the context
element to point tomcat to my getimg webapp when I have located
it outside of the tomcat/webapp directory (for example, with
docbase=/tmp/getimg or docbase=/usr/scratch/getimg) but tomcat
and the webapp still cannot see the linked-in subdirectory at all.

Pull-eesse help!!!  Pleease!!

Maurice Yarrow


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: no luck with allowLinking=true

2005-09-11 Thread Maurice Yarrow

Darek

Thanks for taking the time to look this over.
I tried again, as you suggested.  I did a search
for any extraneous context fragment files that
might conflict somehow:

   ls | while read dir;do echo = $dir;
 find $dir -name \*xml \
 -exec grep -i 'context' {} \; ;
done

and I found nothing.  I don't get any errors
in the catalina.out upon tomcat startup or
when I attempt to access this linked directory,
only a 404 from the browser.
The linked directory is in fact owned by user
tomcat (tomcat is su'd to user tomcat on startup,
by the way.)  As I mentioned in my first letter,
the context element (not including the Resources
element) does indeed work to point the webapp
getimg to any directory in which I put the getimg
tree,  so that is not a problem.

I know from previous experience that just about
any time something doesn't work as it's supposed
to, then I am making some configuration error.
That guiding rule leads me to try virtually every
possible combination of setups until what I am
trying to do works - it's brutal, but effective.
I am also very thorough in my research of
available documentation.  In this particular case,
this is actually the third pass I am making at
getting symlinks to work.  And so, of course,
I am pretty surprised that whatever it is that
I am doing wrong has eluded my efforts so far.

If it is of any help, I could additionally send
any other configuration setups that might be
related.

Thanks again.
Maurice


Darek Czarkowski wrote:

On Sun, 11 Sep 2005 16:55:38 -0700
 Maurice Yarrow [EMAIL PROTECTED] wrote:


Hello tomcat-users

I have simply had no success getting allowLinking=true.
I have read
simply dozens and dozens of links with a standard recipe
for doing this,
as well as the tomcat documentation, of course.

Am running 5.0.28  (tried it in 5.0.30, as well, with same
lack of success).

I have tried placing the context fragment (which, as a
separate file,
I call getimg.xml) in virtually every place I could think
of, as well as
the recommended locations:

   tomcat/conf/Catalina/localhost/getimg.xml

   In the server.xml host element (at the bottom of
the element)

   In the webapps directory...

This is the context fragment I am using:

Context path=/getimg
docBase=getimg
debug=0
reloadable=true
crossContext=true
   Resources
className=org.apache.naming.resources.FileDirContext
  allowLinking=true /
/Context

I then place the following symbolic link in the
webapps/getimg
directory:

   ln -s /usr/scratch/images images

and reboot tomcat.  But, no visibility whatsoever!  Of
course,
when I actually mkdir a directory in webapps/getimg, files
in
this directory are visible, but not with a symlink, and of
course
I don't want to have to actually put gigabytes of stuff in
the
tomcat tree.  I have, however, successfully used the
context
element to point tomcat to my getimg webapp when I have
located
it outside of the tomcat/webapp directory (for example,
with
docbase=/tmp/getimg or docbase=/usr/scratch/getimg)
but tomcat
and the webapp still cannot see the linked-in subdirectory
at all.

Pull-eesse help!!!  Pleease!!

Maurice Yarrow


-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]




Try again, make sure you have only one declaration of
context, since you could be overriding the declaration by
including the incorrect one. Also make sure that user used
to run tomcat has read access to the directory you created.

DarekC

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]