RE: Problem building Tomcat connector

2013-09-18 Thread Casper Wandahl Schmidt
See inline.

De bedste hilsner/ Best regards


Casper Wandahl Schmidt | ExpandIT Mobile ApS
Udviklingskonsulent

c...@expandit.com | T: +45 70 26 86 19 | M: +45 50 44 46 33
www.expandit.com | Nyhedsbrev | Se katalog




-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: 18. september 2013 16:05
To: Tomcat Users List
Subject: Re: Problem building Tomcat connector

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Casper,

On 9/17/13 3:01 PM, Casper Wandahl Schmidt wrote:
> After being away from this list for some time I’m now back for help. I 
> recently upgraded my home server to Ubuntu 12.04.2 LTS with Apache 
> 2.2.22. I’m now trying to build the tomcat connector to get tomcat 
> (not installed yet, but think I will go for newest Tomcat 8 when time 
> comes) and apache to communicate.

Should be no problem to get these set up.

> I have downloaded the source and unpacked it.

You are talking about the "Tomcat Connector", mod_jk, right?

CWS: Yes, sorry, thought it was clear from the subject line :)

> I then do cd native/ and tried ./configure
> –with-apxs=/usr/bin/apxs2 but the command fails saying: “configure:
> error: C++ preprocessor ‘/lib/cpp’ fails sanity check”.
> 
> 
> Config.log has the following to say:
> 
> [snip]
> 
> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
> 
> [snip]
> 
> configure:5036: checking for g++
> 
> configure:5065: result: no
> 
> configure:5036: checking for c++
> 
> configure:5065: result: no
> 
> configure:5036: checking for gpp
> 
> configure:5065: result: no
> 
> configure:5036: checking for aCC
> 
> configure:5065: result: no
> 
> configure:5036: checking for CC
> 
> configure:5065: result: no
> 
> configure:5036: checking for cxx
> 
> configure:5065: result: no
> 
> configure:5036: checking for cc++
> 
> configure:5065: result: no
> 
> configure:5036: checking for cl
> 
> configure:5065: result: no
> 
> configure:5036: checking for FCC
> 
> configure:5065: result: no
> 
> configure:5036: checking for KCC
> 
> configure:5065: result: no
> 
> configure:5036: checking for RCC
> 
> configure:5065: result: no
> 
> configure:5036: checking for xlC_r
> 
> configure:5065: result: no
> 
> configure:5036: checking for xlC
> 
> configure:5065: result: no
> 
> configure:5078: checking for C++ compiler version
> 
> configure:5081: g++ --version &5


Boy, for knowing that g++ doesn't exist, configure sure seems to want to 
interrogate the hell out of it...

> configure:5666: error: C++ preprocessor "/lib/cpp" fails sanity check
> 
> See `config.log' for more details.


Although it does not explicitly state it anywhere in the documentation, you'll 
need to have a C++ compiler installed.

You'll need to install the 'g++' package on Debian/Ubuntu in order to compile 
mod_jk.

I'm not sure why a c++ compiler is required. It does not appear to be a 
requirement for httpd. 

CWS: "sudo apt-get install g++" did fix the problem and mod_jk.so is now 
compiled :)

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSObL4AAoJEBzwKT+lPKRY58AQAJAFOrCalyibTfOnoAdEBRfZ
P6zpWShxA/TnsU31QB11K9dbsJ3i7Xv9yOOYCJryNOBP5fETEzdDUqnbc2kFeGNu
tZh5wNTLNMlWaXgnbOgYqjDmmz53XpQ2saIGBel8PnEhix5qsXWHr9HJSOs7jwJk
5yUSMRm8/3l92vW4bxFnVs0eperlfZFEeMAk8Yh2v9ciXmiHAz38iHqJZWpiBr4o
SV9iNKgOfZYkGtf2AYt7IR7XF52gR7goSf18tJy0e8imFJXTfGhcsiuu/I289ed+
5lu0CEaSLHPLDbKpmALNOVV2hWidVDmZ/0m8Zuv287Mdulkbp1u3G5INbdb4A/4I
v6aYIOJhw3ZY2HbeOM7ERRo8n0331RVOYKyOC+IycD6NE6MFC4MGb3t4uWFnQOdG
VOcPHbsayqu5Ph0RGkDeUsWTevWLUXAIkbeTIf/ymLhN1c6BraYHyDR3497Wa0uQ
guQS+9U2Bf1sGs3/0hqReyE6DS5KnrTWXhnuCFCDYL74CoyY60JLhnaitFfvGI+J
uBRKVj7wWQG1/fl/LZCClNkQ3o93isZe/yjYhWfcFlOZuHYix/PAjGRaerCPKvzf
LNzFQnW0Cw3jWvvKhLe0qOLeGHulLcZUrxMdyt2mUcqteM1D1ncqixESVyQYfmnN
COBqVzC3iigb6FJwnP+w
=gH3d
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Tomcat classes from previous run remains

2013-09-18 Thread Saurabh Saraswat
Dear All,

I am running an j2ee application which uses spring, hibernate, jsf, etc.
the application also uses ha-jdbc to make the databases highly available.
when the application is deployed for the first time, the app runs smoothly,
but when it is un-deployed and deployed back, tomcat gives the following
error:

The following web applications were stopped (reloaded, undeployed), but
their classes from previous runs are still loaded in memory, thus causing a
memory leak (use a profiler to confirm):

I am wondering how to get rid of this problem.

One Solution is restarting the server.
Please let me know the solution with out restarting the server if any.

Thanking You!!


*Best Regards,*

*Saurabh Sarasvat*


RSocket Error

2013-09-18 Thread Divya Prakash



Hi Folks,



We are getting below random error while sending request from one web 
application to another.



It is messing up the live application only for some of the requests.



java.net.SocketException: Connection reset

at java.net.SocketInputStream.read(SocketInputStream.java:168)

at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)

at java.io.BufferedInputStream.read(BufferedInputStream.java:237)

at 
org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)

at 
org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)

at 
org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)

at 
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1413)

at 
org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)

at 
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)

at 
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)

at 
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)

at 
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)

at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)

at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)

at 
com.btsl.flares.apps.mmoney.communicator.HTTPCommunicator.sendHTTPMessage(HTTPCommunicator.java:240)

at 
com.btsl.flares.apps.mmoney.acceptor.handler.OneShotRequestHandler.processResponse(OneShotRequestHandler.java:81)

at 
com.btsl.flares.apps.mmoney.utils.MessageProcessor.run(MessageProcessor.java:96)





Please suggest what could be possible reason and fixes for the above issue.


TXN = jdk1.6.0_33

OS: Linux on Solaris



Regards,

Divya

This e-mail and all material transmitted with it are for the use of the 
intended recipient(s) ONLY and contains confidential and/or privileged 
information. If you are not the intended recipient, please contact the sender 
by reply e-mail and destroy all copies and the original message. Any 
unauthorized review, use, disclosure, dissemination, forwarding, printing or 
copying of this email or any action taken pursuant to the contents of the 
present e-mail is strictly prohibited and is unlawful. The recipient 
acknowledges that Comviva Technologies Limited or its management or directors, 
are unable to exercise control or ensure the integrity over /of the contents of 
the information contained in e-mail. Any views expressed herein are those of 
the individual sender only and no binding nature of the contents shall be 
implied or assumed unless the sender does so expressly with due authority of 
Comviva Technologies Limited. E-mail and any contents transmitted with it are 
prone to viruses and related defects despite all efforts to avoid such by 
Comviva Technologies Limited.


Re: Problems with Clustering / Session Replication

2013-09-18 Thread Vince Stewart
alternatively try an explicit address in the
Receiver configuration


instead of address="auto" try address="192.168.1.43"
this should alter the log displayed at start-up and I would be very
interested if you still had a problem.



On Thu, Sep 19, 2013 at 10:35 AM, Vince Stewart wrote:

> Hi Nicholas,
>
> I'm am a bit of a novice but I did have a very similar problem when I
> started using the clustering modules.
> My Tomcat output was referring to localhost (10.x.x.x) addresses while my
> netstat was reporting LISTEN on network addresses (192.x.x.x:400?).
> You have the same disparity. My system operated to expectation after I
> registered my machine's network IP address in linux folder /etc/hosts.
> Once I did that tomcat clustering logs started reporting membership with
> network addresses instead of localhost addresses.
>
>
>
>
>
> On Thu, Sep 19, 2013 at 2:37 AM, Mark Eggers wrote:
>
>> On 9/18/2013 6:00 AM, Nicholas Violi wrote:
>>
>>> Thanks Daniel.
>>>
>>> On Tue, Sep 17, 2013 at 5:30 PM, Daniel Mikusa >> >wrote:
>>>

 Tried a quick two node setup on my Mac w/out HTTPD and it worked OK.  Go
 to one Tomcat instance's port in chrome, it increments the counter in my
 app.  Refresh a few times.  Open a second tab, go to the second Tomcat
 instance's port.  The counter picks up where it left off and continues
 incrementing.   Flipping back and forth between tabs / servers works
 fine.

 Here's the cluster config that I used in case it helps.

   >>>
   className="org.apache.**catalina.ha.tcp.**SimpleTcpCluster">
  >>> className="org.apache.**catalina.ha.session.**DeltaManager"
   expireSessionsOnShutdown="**false"
   notifyListenersOnReplication="**true"/>
  >>> className="org.apache.**catalina.tribes.group.**GroupChannel">
  >>>
 className="org.apache.**catalina.tribes.membership.**McastService"
  dropTime="3000"
  frequency="500"
  port="45564"/>
  >>>autoBind="100"

 className="org.apache.**catalina.tribes.transport.nio.**NioReceiver"
maxThreads="6"
port="4000"
selectorTimeout="5000"/>
  >>> className="org.apache.**catalina.tribes.transport.**
 ReplicationTransmitter">
  >>> className="org.apache.**catalina.tribes.transport.nio.**
 PooledParallelSender"/>
  
  >>> className="org.apache.**catalina.tribes.group.**interceptors.**
 TcpFailureDetector"/>
  >>> className="org.apache.**catalina.tribes.group.**interceptors.**
 MessageDispatch15Interceptor"/**>
  
  >>> className="org.apache.**catalina.ha.tcp.**ReplicationValve"
 filter=""/>
  >>> className="org.apache.**catalina.ha.session.**JvmRouteBinderValve"/>
  >>> className="org.apache.**catalina.ha.session.**
 JvmRouteSessionIDBinderListene**r"/>
  >>> className="org.apache.**catalina.ha.session.**ClusterSessionListener"/>
  


>>> Just tried this with the same results. My test that replication is
>>> behaving
>>> is accessing my webapp on the two ports and monitoring the session
>>> counter
>>> and list in the tomcat manager, and as I said before, I can only see the
>>> sessions created on the server attached to the manager instance. Is that
>>> a
>>> reasonable test? With the clustering config pretty well ruled out as the
>>> culprit, maybe my webapp is not dealing with sessions appropriately?
>>> Would
>>> you mind sending me your counter test app?
>>>
>>> Beyond that, have you tried increasing the log levels?
>>>
>>>
>>> I found conflicting information about enabling logging. What I had
>>> previously was
>>>
>>> org.apache.catalina.tribes.**level = FINE
>>> org.apache.catalina.tribes.**MESSAGES = FINE
>>>
>>> in logging.properties, which was reporting the FINE log statements in my
>>> original post. I just added some more:
>>>
>>> org.apache.catalina.ha.level = FINE
>>> org.apache.catalina.ha.**session.level = FINE
>>> org.apache.catalina.ha.**session.DeltaManager.level = FINE
>>> org.apache.catalina.ha.tcp.**level = FINE
>>> org.apache.catalina.ha.tcp.**level = FINE
>>> org.apache.catalina.ha.tcp.**ReplicationValve.level = FINE
>>> org.apache.catalina.ha.**session.**ClusterSessionListener.level = FINE
>>> org.apache.catalina.ha.**session.**JvmRouteSessionIDBinterListene**r.level
>>> = FINE
>>>
>>> And I still don't see any messages when interacting with the webapp in
>>> the
>>> browser. Are there a

Re: Problems with Clustering / Session Replication

2013-09-18 Thread Vince Stewart
Hi Nicholas,

I'm am a bit of a novice but I did have a very similar problem when I
started using the clustering modules.
My Tomcat output was referring to localhost (10.x.x.x) addresses while my
netstat was reporting LISTEN on network addresses (192.x.x.x:400?).
You have the same disparity. My system operated to expectation after I
registered my machine's network IP address in linux folder /etc/hosts.
Once I did that tomcat clustering logs started reporting membership with
network addresses instead of localhost addresses.





On Thu, Sep 19, 2013 at 2:37 AM, Mark Eggers  wrote:

> On 9/18/2013 6:00 AM, Nicholas Violi wrote:
>
>> Thanks Daniel.
>>
>> On Tue, Sep 17, 2013 at 5:30 PM, Daniel Mikusa > >wrote:
>>
>>>
>>> Tried a quick two node setup on my Mac w/out HTTPD and it worked OK.  Go
>>> to one Tomcat instance's port in chrome, it increments the counter in my
>>> app.  Refresh a few times.  Open a second tab, go to the second Tomcat
>>> instance's port.  The counter picks up where it left off and continues
>>> incrementing.   Flipping back and forth between tabs / servers works
>>> fine.
>>>
>>> Here's the cluster config that I used in case it helps.
>>>
>>>   >>
>>>   className="org.apache.**catalina.ha.tcp.**SimpleTcpCluster">
>>>  >> className="org.apache.**catalina.ha.session.**DeltaManager"
>>>   expireSessionsOnShutdown="**false"
>>>   notifyListenersOnReplication="**true"/>
>>>  >> className="org.apache.**catalina.tribes.group.**GroupChannel">
>>>  >>
>>> className="org.apache.**catalina.tribes.membership.**McastService"
>>>  dropTime="3000"
>>>  frequency="500"
>>>  port="45564"/>
>>>  >>autoBind="100"
>>>
>>> className="org.apache.**catalina.tribes.transport.nio.**NioReceiver"
>>>maxThreads="6"
>>>port="4000"
>>>selectorTimeout="5000"/>
>>>  >> className="org.apache.**catalina.tribes.transport.**
>>> ReplicationTransmitter">
>>>  >> className="org.apache.**catalina.tribes.transport.nio.**
>>> PooledParallelSender"/>
>>>  
>>>  >> className="org.apache.**catalina.tribes.group.**interceptors.**
>>> TcpFailureDetector"/>
>>>  >> className="org.apache.**catalina.tribes.group.**interceptors.**
>>> MessageDispatch15Interceptor"/**>
>>>  
>>>  >> className="org.apache.**catalina.ha.tcp.**ReplicationValve"
>>> filter=""/>
>>>  >> className="org.apache.**catalina.ha.session.**JvmRouteBinderValve"/>
>>>  >> className="org.apache.**catalina.ha.session.**
>>> JvmRouteSessionIDBinderListene**r"/>
>>>  >> className="org.apache.**catalina.ha.session.**ClusterSessionListener"/>
>>>  
>>>
>>>
>> Just tried this with the same results. My test that replication is
>> behaving
>> is accessing my webapp on the two ports and monitoring the session counter
>> and list in the tomcat manager, and as I said before, I can only see the
>> sessions created on the server attached to the manager instance. Is that a
>> reasonable test? With the clustering config pretty well ruled out as the
>> culprit, maybe my webapp is not dealing with sessions appropriately? Would
>> you mind sending me your counter test app?
>>
>> Beyond that, have you tried increasing the log levels?
>>
>>
>> I found conflicting information about enabling logging. What I had
>> previously was
>>
>> org.apache.catalina.tribes.**level = FINE
>> org.apache.catalina.tribes.**MESSAGES = FINE
>>
>> in logging.properties, which was reporting the FINE log statements in my
>> original post. I just added some more:
>>
>> org.apache.catalina.ha.level = FINE
>> org.apache.catalina.ha.**session.level = FINE
>> org.apache.catalina.ha.**session.DeltaManager.level = FINE
>> org.apache.catalina.ha.tcp.**level = FINE
>> org.apache.catalina.ha.tcp.**level = FINE
>> org.apache.catalina.ha.tcp.**ReplicationValve.level = FINE
>> org.apache.catalina.ha.**session.**ClusterSessionListener.level = FINE
>> org.apache.catalina.ha.**session.**JvmRouteSessionIDBinterListene**r.level
>> = FINE
>>
>> And I still don't see any messages when interacting with the webapp in the
>> browser. Are there any other classes I should be logging?
>>
>> Thanks,
>> Nick
>>
>>
> Copy-pasted from a message I sent to the mailing list about 3 weeks ago:
>
> It's been a while since I've played with this, so your mileage may vary.
>
> # wrapped for easier reading
> # added one additional handler
>
> handlers = 1catalina.org.apache.juli.**FileHandler,
>2localhost.org.apache.juli.**FileHandler,
>3manager.org.apache.ju

[OT] (Non-ASF) Tomcat meet-up next week in San Francisco

2013-09-18 Thread Mark Thomas
I'm speaking at JavaOne next week [1] on building WebSocket support on
top of Servlet 3.1 and the challenges with doing that.

$work has taken advantage of the fact that I am in town to schedule one
of their 'Pivotal Open Source Hub' events [2] on 'Everything Tomcat'
where I'll be talking about Tomcat 8 and anything else Tomcat related
folks want to discuss. There are still places available so do sign up if
you are near San Francisco next week and would like to come along.

Mark

[1]
https://oracleus.activeevents.com/2013/connect/sessionDetail.ww?SESSION_ID=3651
[2] http://www.meetup.com/Pivotal-Open-Source-Hub/events/136113432/

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: [Tomcat-7.0.42/JmxRemoteLifecycleListener] rmiBindAddress vs localhost

2013-09-18 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Marcin,

On 9/18/13 8:58 AM, Marcin Domański wrote:
> 2013/9/12 
>> On 9/11/13 2:29 PM, Marcin Domański wrote:
>>> Hi there! I am trying to setup a Tomcat instance using only 
>>> specific address for all communications. This is convenient for
>>> us from the point of IPsec. I was able to succeed in http,
>>> https, ajp, etc. but for JMX I still cannot get it right. For
>>> this example, let's assume, my desired address is 127.2.0.1.
>>> Currently my configuration is as follows:
>>> 
>>> - >> className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
>>>
>>> 
rmiRegistryPortPlatform="9012" rmiServerPortPlatform="9013"
>>> useLocalPorts="true" />
>>> 
>>> 
>>> Which allows to connect to the server at 
>>> "service:jmx:rmi:///jndi/rmi:// 127.2.0.1:9012/jmxrmi but also 
>>> localhost (means I cannot run second instance with different
>>> IP)
>> 
>> Hmm. I would have expected "useLocalPorts" to bind only to
>> 127.0.0.1 (i.e. localhost). What does netstat tell you under this
>> configuration?
> 
> I see open ports to 127.2.0.1:9012 whenever I have rmiBindAddress
> set and applied patch in JmxRemoteLifecycleListener to use
> rmiBindAddress instead of localhost around line 304, otherwise I
> get exception whenever I use rmiBindAddress=127.2.0.1 and no ports
> are open.

What patch did you apply?

> Netstat with patch and rmiBindAddress=127.0.2.1 and
> useLocalPorts=false: TCP   127.0.2.1:9012 XXX:0
> LISTENING TCP   127.0.2.1:9013 XXX:0
> LISTENING
> 
> Netstat with patch and rmiBindAddress=127.0.2.1 and
> useLocalPorts=true:
> 
> TCP   127.0.2.1:9012 XXX:0LISTENING TCP
> 127.0.2.1:9013 XXX:0LISTENING

That certainly looks like useLocalPorts is not doing anything in your
configuration. I suppose it depends upon whatever patch you applied. I
don't think you should require a patch... just don't use
useLocalPorts=true and let rmiBindAddresss do its job.

Isn't the above what you wanted? To bind on the VPN interface?

> Seems that it connects differently because I see it using localhost
> for connections to port 9013 and 127.0.2.1 for  9012 (remote
> address in netstat)

The above look identical to me (both ports are are for 127.0.2.1). Am
I missing something?

>>> On Windows machine I get a network error basically saying there
>>> is no server configured at localhost in 
>>> JmxRemoteLifecycleListener:304.
>> 
>> You get this on startup? Post the full stack trace, please.
>> 
> 
> Yes, it is a startup of Tomcat itself, not my J2EE application. You
> can try it yourself. Stack is as follows:
> 
> java.io.IOException: Cannot bind to URL
> [rmi://localhost:9012/jmxrmi]: 
> javax.naming.ServiceUnavailableException [Root exception is 
> java.rmi.ConnectException: Connection refused to host: localhost;
> nested exception is: java.net.ConnectException: Connection refused:
> connect]

I think it's important for you to tell us what your patch does. Nobody
knows what you've done in there.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSOesRAAoJEBzwKT+lPKRY6BMQALWgjldYM/1JGZ0Vhs5ge5bz
rV90oDZb8k+iLPQIU2X1Rf7/znWz8DauAFvAwS5ghvgljdKBtZuoA6VDVZIzb+BV
eERg8Cbe07XY38Jw65chW5YKdxxy2+bMPdAvb5xkO3LjTTJfIkB5ZL8EigvTTaKY
zlrk2SreRzSyZiYNvqSjKoUpRMfnVL4EhvXwDauXFSnLnINE4T0CTwJ5lm0Wy3lS
5SDFuAZKRHQ6phEPnRxy0b0CekW3Pucw7m+um/07P2yI3ygkSGRH1hgZPIudDH2E
98I2ei5HdRtgNEMYUbPqpSioaz309nQjb6cVmjnfdInLN0TApw9QTbQG3Yryg8Kx
YSwaiMwid2TCvj+KNine4pvmRZ9ddFyslpBO7aqVR/G4Voqgg+ToxRbkqH3pdBqy
32qv3/gLJA7Mame9+0j/X9/+MbsyJqnuHcW+290ERXe5C2gXUXxnWhuLRBqRkKyl
+Kr5zh6X5fgO7OX884PjXtvvpZfibGJO66OFTNZDMma02mCjJDnWuNX37I+FXMva
PhLqpv7kgB5KbtwG+kliyyxRY9ygfQ/xDudL6d5WCxVjzq7OOxbr+lwxvEHKYfb6
Rz8JVPcgfqmuJ7QshT7vCkUOlGgTsJGxNnXC2n2KgdqeJhhO8TrDgG+QXtChR4SW
DaE8PEM0m/u3XpKsUoBs
=a8eK
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



tomcat7-maven-plugin enable auto deployment under webapps

2013-09-18 Thread Greg Amerson
Hello fellow tomcat7-maven-plugin users,

Is there a way to configure the embedded tomcat launched via the
tomcat7-maven-plugin in such a way that the
${project.build.directory}/tomcat/webapps folder will be monitored for
automatic deployments like it is with a standard tomcat bundle?

I dug around in the source of tomcat7-maven-plugin and even experimented
with my own modified version of the plugin where I added a HostConfig()
object to the embedded tomcat instance.  This seems to get the scanning of
"webapps" folder working again but when it goes to hot-deploy any webapps
out there, it quickly runs into ClassNotFound exceptions because the
WebappClassLoader for the thread that is hot-deploy my new webapp doesn't
have the right parent classloader.

I see where the tomcat7-maven-plugin is creating the WebappClassLoader for
all of the configured contexts via the  config section for the
maven plugin.  But I'm not sure how to get the WebappClassLoaders that are
created by the HostConfig.deployDirectory() to do the same.

Any clues?  Appreciate the help anyone can give.

-- 
Greg Amerson
Liferay Developer Tools
Liferay, Inc. www.liferay.com


Re: Problems with Clustering / Session Replication

2013-09-18 Thread Mark Eggers

On 9/18/2013 6:00 AM, Nicholas Violi wrote:

Thanks Daniel.

On Tue, Sep 17, 2013 at 5:30 PM, Daniel Mikusa wrote:


Tried a quick two node setup on my Mac w/out HTTPD and it worked OK.  Go
to one Tomcat instance's port in chrome, it increments the counter in my
app.  Refresh a few times.  Open a second tab, go to the second Tomcat
instance's port.  The counter picks up where it left off and continues
incrementing.   Flipping back and forth between tabs / servers works fine.

Here's the cluster config that I used in case it helps.

  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 



Just tried this with the same results. My test that replication is behaving
is accessing my webapp on the two ports and monitoring the session counter
and list in the tomcat manager, and as I said before, I can only see the
sessions created on the server attached to the manager instance. Is that a
reasonable test? With the clustering config pretty well ruled out as the
culprit, maybe my webapp is not dealing with sessions appropriately? Would
you mind sending me your counter test app?

Beyond that, have you tried increasing the log levels?


I found conflicting information about enabling logging. What I had
previously was

org.apache.catalina.tribes.level = FINE
org.apache.catalina.tribes.MESSAGES = FINE

in logging.properties, which was reporting the FINE log statements in my
original post. I just added some more:

org.apache.catalina.ha.level = FINE
org.apache.catalina.ha.session.level = FINE
org.apache.catalina.ha.session.DeltaManager.level = FINE
org.apache.catalina.ha.tcp.level = FINE
org.apache.catalina.ha.tcp.level = FINE
org.apache.catalina.ha.tcp.ReplicationValve.level = FINE
org.apache.catalina.ha.session.ClusterSessionListener.level = FINE
org.apache.catalina.ha.session.JvmRouteSessionIDBinterListener.level = FINE

And I still don't see any messages when interacting with the webapp in the
browser. Are there any other classes I should be logging?

Thanks,
Nick



Copy-pasted from a message I sent to the mailing list about 3 weeks ago:

It's been a while since I've played with this, so your mileage may vary.

# wrapped for easier reading
# added one additional handler

handlers = 1catalina.org.apache.juli.FileHandler,
   2localhost.org.apache.juli.FileHandler,
   3manager.org.apache.juli.FileHandler,
   4host-manager.or.apache.juli.FileHandler,
java.util.logging.ConsoleHandler,
   5cluster.org.apache.juli.FileHandler

# just the new cluster log handler - all others are stock
# logging.properties
# beware of the wrapping

5cluster.org.apache.juli.FileHandler.level = FINER
5cluster.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
5cluster.org.apache.juli.FileHandler.prefix = cluster.

# just the clustering logs - all others are stock logging.properties
org.apache.catalina.tribes.MESSAGES.level = FINE
org.apache.catalina.tribes.MESSAGES.handlers =
5cluster.org.apache.juli.FileHandler

org.apache.catalina.tribes.level = FINE
org.apache.catalina.tribes.handlers =
5cluster.org.apache.juli.FileHandler

org.apache.catalina.ha.level = FINE
org.apache.catalina.ha.handlers = 5cluster.org.apache.juli.FileHander

org.apache.catalina.ha.deploy.level = INFO
org.apache.catalina.ha.deploy.handlers =
5cluster.org.apache.juli.FileHandler

Set logging at the desired level.

I think I've posted this to the mailing list before . . .

/mde/

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Problem building Tomcat connector

2013-09-18 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Casper,

On 9/17/13 3:01 PM, Casper Wandahl Schmidt wrote:
> After being away from this list for some time I’m now back for
> help. I recently upgraded my home server to Ubuntu 12.04.2 LTS with
> Apache 2.2.22. I’m now trying to build the tomcat connector to get
> tomcat (not installed yet, but think I will go for newest Tomcat 8
> when time comes) and apache to communicate.

Should be no problem to get these set up.

> I have downloaded the source and unpacked it.

You are talking about the "Tomcat Connector", mod_jk, right?

> I then do cd native/ and tried ./configure
> –with-apxs=/usr/bin/apxs2 but the command fails saying: “configure:
> error: C++ preprocessor ‘/lib/cpp’ fails sanity check”.
> 
> 
> Config.log has the following to say:
> 
> [snip]
> 
> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
> 
> [snip]
> 
> configure:5036: checking for g++
> 
> configure:5065: result: no
> 
> configure:5036: checking for c++
> 
> configure:5065: result: no
> 
> configure:5036: checking for gpp
> 
> configure:5065: result: no
> 
> configure:5036: checking for aCC
> 
> configure:5065: result: no
> 
> configure:5036: checking for CC
> 
> configure:5065: result: no
> 
> configure:5036: checking for cxx
> 
> configure:5065: result: no
> 
> configure:5036: checking for cc++
> 
> configure:5065: result: no
> 
> configure:5036: checking for cl
> 
> configure:5065: result: no
> 
> configure:5036: checking for FCC
> 
> configure:5065: result: no
> 
> configure:5036: checking for KCC
> 
> configure:5065: result: no
> 
> configure:5036: checking for RCC
> 
> configure:5065: result: no
> 
> configure:5036: checking for xlC_r
> 
> configure:5065: result: no
> 
> configure:5036: checking for xlC
> 
> configure:5065: result: no
> 
> configure:5078: checking for C++ compiler version
> 
> configure:5081: g++ --version &5


Boy, for knowing that g++ doesn't exist, configure sure seems to want
to interrogate the hell out of it...

> configure:5666: error: C++ preprocessor "/lib/cpp" fails sanity
> check
> 
> See `config.log' for more details.


Although it does not explicitly state it anywhere in the
documentation, you'll need to have a C++ compiler installed.

You'll need to install the 'g++' package on Debian/Ubuntu in order to
compile mod_jk.

I'm not sure why a c++ compiler is required. It does not appear to be
a requirement for httpd.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSObL4AAoJEBzwKT+lPKRY58AQAJAFOrCalyibTfOnoAdEBRfZ
P6zpWShxA/TnsU31QB11K9dbsJ3i7Xv9yOOYCJryNOBP5fETEzdDUqnbc2kFeGNu
tZh5wNTLNMlWaXgnbOgYqjDmmz53XpQ2saIGBel8PnEhix5qsXWHr9HJSOs7jwJk
5yUSMRm8/3l92vW4bxFnVs0eperlfZFEeMAk8Yh2v9ciXmiHAz38iHqJZWpiBr4o
SV9iNKgOfZYkGtf2AYt7IR7XF52gR7goSf18tJy0e8imFJXTfGhcsiuu/I289ed+
5lu0CEaSLHPLDbKpmALNOVV2hWidVDmZ/0m8Zuv287Mdulkbp1u3G5INbdb4A/4I
v6aYIOJhw3ZY2HbeOM7ERRo8n0331RVOYKyOC+IycD6NE6MFC4MGb3t4uWFnQOdG
VOcPHbsayqu5Ph0RGkDeUsWTevWLUXAIkbeTIf/ymLhN1c6BraYHyDR3497Wa0uQ
guQS+9U2Bf1sGs3/0hqReyE6DS5KnrTWXhnuCFCDYL74CoyY60JLhnaitFfvGI+J
uBRKVj7wWQG1/fl/LZCClNkQ3o93isZe/yjYhWfcFlOZuHYix/PAjGRaerCPKvzf
LNzFQnW0Cw3jWvvKhLe0qOLeGHulLcZUrxMdyt2mUcqteM1D1ncqixESVyQYfmnN
COBqVzC3iigb6FJwnP+w
=gH3d
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Audit Exceptions on Apache

2013-09-18 Thread Daniel Mikusa
On Sep 18, 2013, at 9:00 AM, Obba Joy  wrote:

> Hello Team,

Please don't post the same message to the list twice.  This list is made up of 
volunteers who will respond to your request as they have time.  If you need a 
faster response or more hand holding, please consider purchasing a support 
contract from one of the many companies that offer this service.

> Some security issues were raised by our audit team and these
>  issues were forwarded to secur...@apache.org.
> We got a response from Mark Thomas from the Security team
> Theses issues are listed below:
> 
> 1. Banner Disclosure 
> We observed that the GTApplication web server disclosed the
>  Apache Coyote version in its HTTP response. The extracted version
>  is: Apache-Coyote/1.1
> Risk 
>  This information might help an attacker gain a greater understanding of 
> the systems in use and potentially develop further attacks targeted at the 
> specific version of Apache.
> 
> Response 
> 
> Not a vulnerability in Apache Tomcat. Every currently supported version of 
> Apache Tomcat includes that information in the header. All it tells an 
> attacker is that you are running Apache Tomcat. If you really want to change 
> it, a configuration option to do that is available on the connector. 

Have you looked at the connector docs?

   https://tomcat.apache.org/tomcat-7.0-doc/config/http.html

HINT:  Search for the "server" attribute.

> 2. The Character Set was not set. 
> The Character set (Charset) was not explicitly set by the
>  server.
> Risk
>  There is a risk that characters in content are incorrectly
>  interpreted by the server. Lack of charset can cause the browser
>  to guess the encoding type and this could lead to Cross-site
>  Scripting by encoding the payload in   
>   encoding types like UTF-7. 
>   
> Response
> 
> Not a vulnerability in Apache Tomcat. RFC2616 requires clients to treat 
> responses without a character encoding as being encoding with ISO-8859-1. 
> Clients that try to guess the charset are in breach of RFC2616. Further that 
> they might do so in an unsafe manner is a security vulnerability in those 
> clients and should be reported to the appropriate vendor. If the vendor(s) of 
> the vulnerable client(s) are unwilling to fix this vulnerability there are 
> multiple ways that it could be mitigated. For example, with a filter that 
> always sets the character set. 

Again, docs are your friend.

  
https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Add_Default_Character_Set_Filter

Dan

> 
>  Kindly send documents that will assist us in resolving these vulnerabilities
> 
> Kind Regards


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Audit Exceptions on Apache

2013-09-18 Thread Obba Joy
Hello David,
 
Kindly assist with the documentation I need to use
 
Regards
 


 From: David kerber 
To: Tomcat Users List  
Sent: Wednesday, September 18, 2013 2:09 PM
Subject: Re: Audit Exceptions on Apache
  

On 9/18/2013 5:04 AM, Joy Obba wrote:
> Hello Team,
>
> Some security issues were raised by our audit team and these issues were
> forwarded to secur...@apache.org.
> We got a response from Mark Thomas from the Security team
> Theses issues are listed below:
>
> 1. Banner Disclosure
>      We observed that the GTApplication web server disclosed the Apache
> Coyote version in its HTTP response. The extracted version is:
> Apache-Coyote/1.1
> *Risk *
>       This information might help an attacker gain a greater
> understanding of the systems in use and potentially develop further
> attacks targeted at the specific version of Apache.
>
> ***Response *
>
>       Not a vulnerability in Apache Tomcat. Every currently supported version
>      of Apache Tomcat includes that information in the header. All it tells
>      an attacker is that you are running Apache Tomcat.
>
>      If you really want to change it, a configuration option to do that is
>      available on the connector.
>
> 2. The Character Set was not set.
>      The Character set (Charset) was not explicitly set by the server.
> *  Risk*
>       There is a risk that characters in content are incorrectly
> interpreted by the server. Lack of charset can cause the browser to
> guess the encoding type and this could lead to Cross-site Scripting by
> encoding the payload in
> encoding types like UTF-7.
>
> *   Response*
>
>      Not a vulnerability in Apache Tomcat. RFC2616 requires clients to treat
>      responses without a character encoding as being encoding with
>      ISO-8859-1. Clients that try to guess the charset are in breach of
>      RFC2616. Further that they might do so in an unsafe manner is a security
>      vulnerability in those clients and should be reported to the appropriate
>      vendor.
>
>     If the vendor(s) of the vulnerable client(s) are unwilling to fix this
>     vulnerability there are multiple ways that it could be mitigated. For
>     example, with a filter that always sets the character set.
>
>
>   Kindly send documents that will assist us in resolving these
> vulnerabilities

I think Mark's responses above tell you what you need to know in order 
to resolve these.  Just look in the documentation for the implementation 
details.

D


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Audit Exceptions on Apache

2013-09-18 Thread David kerber

On 9/18/2013 5:04 AM, Joy Obba wrote:

Hello Team,

Some security issues were raised by our audit team and these issues were
forwarded to secur...@apache.org.
We got a response from Mark Thomas from the Security team
Theses issues are listed below:

1. Banner Disclosure
 We observed that the GTApplication web server disclosed the Apache
Coyote version in its HTTP response. The extracted version is:
Apache-Coyote/1.1
*Risk *
  This information might help an attacker gain a greater
understanding of the systems in use and potentially develop further
attacks targeted at the specific version of Apache.

***Response *

  Not a vulnerability in Apache Tomcat. Every currently supported version
 of Apache Tomcat includes that information in the header. All it tells
 an attacker is that you are running Apache Tomcat.

 If you really want to change it, a configuration option to do that is
 available on the connector.

2. The Character Set was not set.
 The Character set (Charset) was not explicitly set by the server.
*  Risk*
  There is a risk that characters in content are incorrectly
interpreted by the server. Lack of charset can cause the browser to
guess the encoding type and this could lead to Cross-site Scripting by
encoding the payload in
encoding types like UTF-7.

*   Response*

 Not a vulnerability in Apache Tomcat. RFC2616 requires clients to treat
 responses without a character encoding as being encoding with
 ISO-8859-1. Clients that try to guess the charset are in breach of
 RFC2616. Further that they might do so in an unsafe manner is a security
 vulnerability in those clients and should be reported to the appropriate
 vendor.

If the vendor(s) of the vulnerable client(s) are unwilling to fix this
vulnerability there are multiple ways that it could be mitigated. For
example, with a filter that always sets the character set.


  Kindly send documents that will assist us in resolving these
vulnerabilities


I think Mark's responses above tell you what you need to know in order 
to resolve these.  Just look in the documentation for the implementation 
details.


D


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Audit Exceptions on Apache

2013-09-18 Thread Obba Joy
Hello Team,

Some security issues were raised by our audit team and these
  issues were forwarded to secur...@apache.org.
We got a response from Mark Thomas from the Security team
Theses issues are listed below:

1. Banner Disclosure 
    We observed that the GTApplication web server disclosed the
  Apache Coyote version in its HTTP response. The extracted version
  is: Apache-Coyote/1.1
    Risk 
 This information might help an attacker gain a greater understanding of 
the systems in use and potentially develop further attacks targeted at the 
specific version of Apache.
    
    Response 

Not a vulnerability in Apache Tomcat. Every currently supported version of 
Apache Tomcat includes that information in the header. All it tells an attacker 
is that you are running Apache Tomcat. If you really want to change it, a 
configuration option to do that is available on the connector. 
2. The Character Set was not set. 
    The Character set (Charset) was not explicitly set by the
  server.
    Risk
 There is a risk that characters in content are incorrectly
  interpreted by the server. Lack of charset can cause the browser
  to guess the encoding type and this could lead to Cross-site
  Scripting by encoding the payload in   
  encoding types like UTF-7. 
  
    Response

Not a vulnerability in Apache Tomcat. RFC2616 requires clients to treat 
responses without a character encoding as being encoding with ISO-8859-1. 
Clients that try to guess the charset are in breach of RFC2616. Further that 
they might do so in an unsafe manner is a security vulnerability in those 
clients and should be reported to the appropriate vendor. If the vendor(s) of 
the vulnerable client(s) are unwilling to fix this vulnerability there are 
multiple ways that it could be mitigated. For example, with a filter that 
always sets the character set. 

 Kindly send documents that will assist us in resolving these
  vulnerabilities

Kind Regards


Re: Problems with Clustering / Session Replication

2013-09-18 Thread Nicholas Violi
Thanks Daniel.

On Tue, Sep 17, 2013 at 5:30 PM, Daniel Mikusa wrote:
>
> Tried a quick two node setup on my Mac w/out HTTPD and it worked OK.  Go
> to one Tomcat instance's port in chrome, it increments the counter in my
> app.  Refresh a few times.  Open a second tab, go to the second Tomcat
> instance's port.  The counter picks up where it left off and continues
> incrementing.   Flipping back and forth between tabs / servers works fine.
>
> Here's the cluster config that I used in case it helps.
>
>  
>  className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
>  className="org.apache.catalina.ha.session.DeltaManager"
>  expireSessionsOnShutdown="false"
>  notifyListenersOnReplication="true"/>
>  className="org.apache.catalina.tribes.group.GroupChannel">
> 
> className="org.apache.catalina.tribes.membership.McastService"
> dropTime="3000"
> frequency="500"
> port="45564"/>
>autoBind="100"
>
> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>   maxThreads="6"
>   port="4000"
>   selectorTimeout="5000"/>
>  className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>  className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
> 
>  className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
>  className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
> 
>  className="org.apache.catalina.ha.tcp.ReplicationValve"
>filter=""/>
>  className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
>  className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
>  className="org.apache.catalina.ha.session.ClusterSessionListener"/>
> 
>

Just tried this with the same results. My test that replication is behaving
is accessing my webapp on the two ports and monitoring the session counter
and list in the tomcat manager, and as I said before, I can only see the
sessions created on the server attached to the manager instance. Is that a
reasonable test? With the clustering config pretty well ruled out as the
culprit, maybe my webapp is not dealing with sessions appropriately? Would
you mind sending me your counter test app?

Beyond that, have you tried increasing the log levels?


I found conflicting information about enabling logging. What I had
previously was

org.apache.catalina.tribes.level = FINE
org.apache.catalina.tribes.MESSAGES = FINE

in logging.properties, which was reporting the FINE log statements in my
original post. I just added some more:

org.apache.catalina.ha.level = FINE
org.apache.catalina.ha.session.level = FINE
org.apache.catalina.ha.session.DeltaManager.level = FINE
org.apache.catalina.ha.tcp.level = FINE
org.apache.catalina.ha.tcp.level = FINE
org.apache.catalina.ha.tcp.ReplicationValve.level = FINE
org.apache.catalina.ha.session.ClusterSessionListener.level = FINE
org.apache.catalina.ha.session.JvmRouteSessionIDBinterListener.level = FINE

And I still don't see any messages when interacting with the webapp in the
browser. Are there any other classes I should be logging?

Thanks,
Nick


Re: [Tomcat-7.0.42/JmxRemoteLifecycleListener] rmiBindAddress vs localhost

2013-09-18 Thread Marcin Domański
Chris,


2013/9/12 

>
>
> Marcin,
>
> On 9/11/13 2:29 PM, Marcin Domański wrote:
> > Hi there! I am trying to setup a Tomcat instance using only
> > specific address for all communications. This is convenient for us
> > from the point of IPsec. I was able to succeed in http, https, ajp,
> > etc. but for JMX I still cannot get it right. For this example,
> > let's assume, my desired address is 127.2.0.1. Currently my
> > configuration is as follows:
> >
> > -  > className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
> > rmiRegistryPortPlatform="9012" rmiServerPortPlatform="9013"
> > useLocalPorts="true" />
> >
> >
> > Which allows to connect to the server at
> > "service:jmx:rmi:///jndi/rmi:// 127.2.0.1:9012/jmxrmi but also
> > localhost (means I cannot run second instance with different IP)
>
> Hmm. I would have expected "useLocalPorts" to bind only to 127.0.0.1
> (i.e. localhost). What does netstat tell you under this configuration?
>

I see open ports to 127.2.0.1:9012 whenever I have rmiBindAddress set and
applied patch in JmxRemoteLifecycleListener to use rmiBindAddress instead
of localhost around line 304, otherwise I get exception whenever I use
rmiBindAddress=127.2.0.1 and no ports are open.

Netstat with patch and rmiBindAddress=127.0.2.1 and useLocalPorts=false:
 TCP   127.0.2.1:9012 XXX:0LISTENING
 TCP   127.0.2.1:9013 XXX:0LISTENING

Netstat with patch and rmiBindAddress=127.0.2.1 and useLocalPorts=true:

 TCP   127.0.2.1:9012 XXX:0LISTENING
 TCP   127.0.2.1:9013 XXX:0LISTENING


Seems that it connects differently because I see it using localhost for
connections to port 9013 and 127.0.2.1 for  9012 (remote address in netstat)



> > On the other hand,when I try following:
> >
> > -  > className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
> > rmiRegistryPortPlatform="9012" rmiServerPortPlatform="9013"
> > useLocalPorts="true" rmiBindAddress="127.2.0.1"/>
> >
> > On Windows machine I get a network error basically saying there is
> > no server configured at localhost in
> > JmxRemoteLifecycleListener:304.
>
> You get this on startup? Post the full stack trace, please.
>

Yes, it is a startup of Tomcat itself, not my J2EE application. You can try
it yourself. Stack is as follows:

java.io.IOException: Cannot bind to URL [rmi://localhost:9012/jmxrmi]:
javax.naming.ServiceUnavailableException [Root exception is
java.rmi.ConnectException: Connection refused to host: localhost; nested
exception is:
java.net.ConnectException: Connection refused: connect]
at
javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServer.java:827)
at
javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:432)
at
org.apache.catalina.mbeans.JmxRemoteLifecycleListener.createServer(JmxRemoteLifecycleListener.java:304)
at
org.apache.catalina.mbeans.JmxRemoteLifecycleListener.lifecycleEvent(JmxRemoteLifecycleListener.java:258)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402)
at
org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:347)
at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:725)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.startup.Catalina.start(Catalina.java:691)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:322)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:456)
Caused by: javax.naming.ServiceUnavailableException [Root exception is
java.rmi.ConnectException: Connection refused to host: localhost; nested
exception is:
java.net.ConnectException: Connection refused: connect]
at
com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:143)
at
com.sun.jndi.toolkit.url.GenericURLContext.bind(GenericURLContext.java:226)
at javax.naming.InitialContext.bind(InitialContext.java:419)
at
javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:644)
at
javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:427)
... 15 more
Caused by: java.rmi.ConnectException: Connection refused to host:
localhost; nested exception is:
java.net.ConnectException: Connection refused: connect
at sun.rmi.transport.tcp.TCPEndpo

Re: Apache Tomcat 8.0.0-RC2

2013-09-18 Thread Mark Thomas
On 18/09/2013 09:05, Mark Thomas wrote:
> On 18/09/2013 01:42, jieryn wrote:
>> I'm trying out the new Apache Tomcat 8.0.0-RC2 with some existing web
>> applications that work fine under Apache Tomcat 8.0.0-RC1.
>>
>> I am now seeing literally thousands of warning messages at start up time:
>>
>> 17-Sep-2013 20:19:40.346 WARNING [hostname-startStop-1]
>> org.apache.catalina.webresources.Cache.getResource Unable to add the
>> resource at [{0}] to the cache because there was insufficient free
>> space available after evicting expired cache entries - consider
>> increasing the maximum size of the cache
>>
>> (Note that the [{0}] is the actual text, which suggests a secondary problem.)
> 
> I'll fix that.
> 
>> Are these messages the result of the Context configuration elements
>> cacheMaxSize, cacheObjectsMaxSize, cacheTTL, and cachingAllowed?
> 
> Yes.
> 
>> Would it be better to not omit these messages at catalina start up if they
>> are for static resources which have been requested by clients?
> 
> No. The cache is used for any web application resource. I suspect the
> problem is that it is currently caching things that shouldn't be cached
> such as class files. I'll take a look.

I've just tried 8.0.0-RC2 with Jira (as an example of a fairly large app
that I know should work without any external plumbing). I've fixed the
broken message and fixed a TODO for excluding some resources from the
cache. Anything loaded by the class loader is now excluded as the class
loader has its own cache (which itself excludes classes).

Those fixes will be in the next RC that hopefully will be out rather
sooner than RC2 was but that depends on the problems folks find and how
long they take to fix.

> Note that apart from filling the logs, there shouldn't be any problem.

I didn't see anything to change this assessment.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Cannot access webapp outside the server box using a public domain name

2013-09-18 Thread Albert Kam
> How exactly does it fail ?
Sorry, it failed with error message stating that it cannot connect to the
myweb.com:80;

> nslookup disregards the local "hosts" file
> What's with the other nodes' local "hosts" file ?
These lines gave me a brain jolt.
It's my mistake, as i mapped myweb.com to 127.0.0.1 locally on my laptop,
which is why it doesnt use dns to get the public ip.

Now that i commented the local mapping in my etc/hosts, everything works
great !
Thank you so much for your help !

Warm regards from Jakarta,
Albert Kam



On Wed, Sep 18, 2013 at 4:50 PM, André Warnier  wrote:

> Albert Kam wrote:
>
>> I have a case where accessing the webapp within the server box is fine,
>> but accessing the webapp from outside the server box using the domain name
>> is problematic, but not so using the public ip address, which is
>> accessible.
>>
>> The content of the webapp is just a single index.html, so no JSPs, no
>> classes are involved.
>>
>> - On my web server, which is set for the public domain myweb.com,
>>   curl http://myweb.com works
>>   curl http:// also works
>>   note : i registered the domain from the domain robot
>>
>> - On external nodes (not on the web server), i tried to access
>>   curl http://myweb.com fails
>>
>
> How exactly does it fail ?  Doesn't curl have some "verbose" option to
> give you the exact failure reason ?
>
>
>But : curl http:// works
>>
>> - Both on the web server and external nodes,
>>   nslookup myweb.com works, and returns the public ip address correctly
>>
>
> Just for info : nslookup disregards the local "hosts" file..
>
>
>
>> - I have even disabled ipv6 in my /etc/hosts and domain mapping
>>   So my current host file is very simple :
>>   127.0.0.1 localhost
>>
>
> Yes, but this concerns only your local host, which was already working
> fine, as per your indications above.
> What's with the other nodes' local "hosts" file ?
>
> On the Tomcat host, can you run the following command and paste the output
> here ?
>
> ifconfig -a
>
>
>
>
>
>
>
>> - Here my output of version.sh
>> Using CATALINA_BASE:   /usr/share/tomcat7
>> Using CATALINA_HOME:   /usr/share/tomcat7
>> Using CATALINA_TMPDIR: /usr/share/tomcat7/temp
>> Using JRE_HOME:/usr/lib/jvm/java-7-oracle
>> Using CLASSPATH:
>> /usr/share/tomcat7/bin/**bootstrap.jar:/usr/share/**
>> tomcat7/bin/tomcat-juli.jar
>> Server version: Apache Tomcat/7.0.28
>> Server built:   Dec 8 2012 06:51:43
>> Server number:  7.0.28.0
>> OS Name:Linux
>> OS Version: 3.2.0-4-amd64
>> Architecture:   amd64
>> JVM Version:1.7.0_25-b15
>> JVM Vendor: Oracle Corporation
>>
>> - Here's my server.xml
>> 
>>
>> 
>>   
>>   > className="org.apache.**catalina.core.**JreMemoryLeakPreventionListene**r"
>> />
>>   > className="org.apache.**catalina.mbeans.**GlobalResourcesLifecycleListen*
>> *er" />
>>   > className="org.apache.**catalina.core.**ThreadLocalLeakPreventionListe**ner"
>> />
>>
>>   
>> >connectionTimeout="2"
>>URIEncoding="UTF-8"
>>redirectPort="8443" address="" />
>>
>> 
>> > unpackWARs="true" autoDeploy="true">
>> myweb.com
>> > directory="logs"
>>prefix="localhost_access_log." suffix=".txt"
>>pattern="%h %l %u %t "%r" %s %b" />
>> 
>> 
>>   
>> 
>>
>> - Here's my ifconfig :
>> root@Debian-70-wheezy-64-**minimal:/home/moonblade# ifconfig
>> eth0  Link encap:Ethernet  HWaddr d4:3d:7e:d8:ba:27
>>   inet addr:  Bcast:
>>  Mask:255.255.255.224
>>   inet6 addr: /64 Scope:Link
>>   inet6 addr: **/64 Scope:Global
>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>   RX packets:290094 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:169056 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000
>>   RX bytes:241176295 (230.0 MiB)  TX bytes:27580533 (26.3 MiB)
>>   Interrupt:43 Base address:0x6000
>>
>> loLink encap:Local Loopback
>>   inet addr:127.0.0.1  Mask:255.0.0.0
>>   inet6 addr: ::1/128 Scope:Host
>>   UP LOOPBACK RUNNING  MTU:16436  Metric:1
>>   RX packets:192 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:192 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:0
>>   RX bytes:26625 (26.0 KiB)  TX bytes:26625 (26.0 KiB)
>>
>> - no firewall, as the iptables are still empty :
>> root@Debian-70-wheezy-64-**minimal:/home/moonblade# iptables -L -n
>> Chain INPUT (policy ACCEPT)
>> target prot opt source   destination
>>
>> Chain FORWARD (policy ACCEPT)
>> target prot opt source   destination
>>
>> Chain OUTPUT (policy ACCEPT)
>> target prot opt source   destination
>>
>> - my system
>> Linux Debian-70-wheezy-64-minimal 3.2.0-4-amd64 #1 SMP Debian
>> 3.2.46-1+deb7u1 x86_64 GNU/Linux
>>
>> Am i missing something in my server.xml ?
>>
>>
>>
>
> --**-

Re: Cannot access webapp outside the server box using a public domain name

2013-09-18 Thread André Warnier

Albert Kam wrote:

I have a case where accessing the webapp within the server box is fine,
but accessing the webapp from outside the server box using the domain name
is problematic, but not so using the public ip address, which is accessible.

The content of the webapp is just a single index.html, so no JSPs, no
classes are involved.

- On my web server, which is set for the public domain myweb.com,
  curl http://myweb.com works
  curl http:// also works
  note : i registered the domain from the domain robot

- On external nodes (not on the web server), i tried to access
  curl http://myweb.com fails


How exactly does it fail ?  Doesn't curl have some "verbose" option to give you the exact 
failure reason ?



  But : curl http:// works

- Both on the web server and external nodes,
  nslookup myweb.com works, and returns the public ip address correctly


Just for info : nslookup disregards the local "hosts" file..



- I have even disabled ipv6 in my /etc/hosts and domain mapping
  So my current host file is very simple :
  127.0.0.1 localhost


Yes, but this concerns only your local host, which was already working fine, as per your 
indications above.

What's with the other nodes' local "hosts" file ?

On the Tomcat host, can you run the following command and paste the output here 
?

ifconfig -a







- Here my output of version.sh
Using CATALINA_BASE:   /usr/share/tomcat7
Using CATALINA_HOME:   /usr/share/tomcat7
Using CATALINA_TMPDIR: /usr/share/tomcat7/temp
Using JRE_HOME:/usr/lib/jvm/java-7-oracle
Using CLASSPATH:
/usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar
Server version: Apache Tomcat/7.0.28
Server built:   Dec 8 2012 06:51:43
Server number:  7.0.28.0
OS Name:Linux
OS Version: 3.2.0-4-amd64
Architecture:   amd64
JVM Version:1.7.0_25-b15
JVM Vendor: Oracle Corporation

- Here's my server.xml



  
  
  
  

  




myweb.com



  


- Here's my ifconfig :
root@Debian-70-wheezy-64-minimal:/home/moonblade# ifconfig
eth0  Link encap:Ethernet  HWaddr d4:3d:7e:d8:ba:27
  inet addr:  Bcast:
 Mask:255.255.255.224
  inet6 addr: /64 Scope:Link
  inet6 addr: /64 Scope:Global
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:290094 errors:0 dropped:0 overruns:0 frame:0
  TX packets:169056 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:241176295 (230.0 MiB)  TX bytes:27580533 (26.3 MiB)
  Interrupt:43 Base address:0x6000

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:192 errors:0 dropped:0 overruns:0 frame:0
  TX packets:192 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:26625 (26.0 KiB)  TX bytes:26625 (26.0 KiB)

- no firewall, as the iptables are still empty :
root@Debian-70-wheezy-64-minimal:/home/moonblade# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

- my system
Linux Debian-70-wheezy-64-minimal 3.2.0-4-amd64 #1 SMP Debian
3.2.46-1+deb7u1 x86_64 GNU/Linux

Am i missing something in my server.xml ?





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: WebSocket message size limits

2013-09-18 Thread Mark Thomas
On 18/09/2013 06:19, Igor Urisman wrote:
> Dear All,
> 
> I am looking for help in understanding why the size of the inbound
> WebSocket message is limited to 125 bytes.

It isn't, at least not by Tomcat.

>  I realize that this may not
> even be the right place for my question, but am still hoping for a clue.
> 
> From looking at the RFC 6455, Sec. 5.2 Base Framing Protocol, I am making
> two conclusions:
> 
> 1. There's nothing in it to suggest a payload length asymmetry between
> inbound and outbound messages.  Yet, although I am able to send very large
> messages to the browser, an attempt to send anything over 125 bytes results
> in error and a connection shutdown.  (I tried FF and Chrome on a Mac).
> 
> 2. It's easy to see from the wire protocol why 125 is the simplest payload
> length but other sizes up to unsigned 64 bit int are supported.  So,
> browser's failure to transmit more than 125 bits indicates both, the most
> restrictive payload size AND lack of support for fragmented messages.
> 
> The error that FF gives reads "The decoded text message was too big for the
> output buffer and the endpoint does not support partial messages" which to
> me reads like they are saying that Tomcat did not indicate during handshake
> that it accepts multi-part messages.  True?

False. There is nothing in the handshake that allows one end not to
support multi-part messages nor to limit the maximum message length.

That looks like a client side issue to me. Maybe you need to make the
client side output buffer bigger.

Tomcat's web socket support (client and server) has been tested with the
Autobahn testsuite that includes tests with significantly larger
messages than 125 bytes both as single frames and as multiple frames.
> 
> I can't speak for others, but for my project 125 bytes is unacceptably
> small.  So, fundamentally what I need to know is this: do I need to
> implement my own fragmenting or am I missing something?

You are missing something. No idea what since you haven't provided any
details of your client side implementation.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Apache Tomcat 8.0.0-RC2

2013-09-18 Thread Mark Thomas
On 18/09/2013 01:42, jieryn wrote:
> I'm trying out the new Apache Tomcat 8.0.0-RC2 with some existing web
> applications that work fine under Apache Tomcat 8.0.0-RC1.
> 
> I am now seeing literally thousands of warning messages at start up time:
> 
> 17-Sep-2013 20:19:40.346 WARNING [hostname-startStop-1]
> org.apache.catalina.webresources.Cache.getResource Unable to add the
> resource at [{0}] to the cache because there was insufficient free
> space available after evicting expired cache entries - consider
> increasing the maximum size of the cache
> 
> (Note that the [{0}] is the actual text, which suggests a secondary problem.)

I'll fix that.

> Are these messages the result of the Context configuration elements
> cacheMaxSize, cacheObjectsMaxSize, cacheTTL, and cachingAllowed?

Yes.

> Would it be better to not omit these messages at catalina start up if they
> are for static resources which have been requested by clients?

No. The cache is used for any web application resource. I suspect the
problem is that it is currently caching things that shouldn't be cached
such as class files. I'll take a look.

Note that apart from filling the logs, there shouldn't be any problem.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Cannot access webapp outside the server box using a public domain name

2013-09-18 Thread Albert Kam
I have a case where accessing the webapp within the server box is fine,
but accessing the webapp from outside the server box using the domain name
is problematic, but not so using the public ip address, which is accessible.

The content of the webapp is just a single index.html, so no JSPs, no
classes are involved.

- On my web server, which is set for the public domain myweb.com,
  curl http://myweb.com works
  curl http:// also works
  note : i registered the domain from the domain robot

- On external nodes (not on the web server), i tried to access
  curl http://myweb.com fails
  But : curl http:// works

- Both on the web server and external nodes,
  nslookup myweb.com works, and returns the public ip address correctly

- I have even disabled ipv6 in my /etc/hosts and domain mapping
  So my current host file is very simple :
  127.0.0.1 localhost

- Here my output of version.sh
Using CATALINA_BASE:   /usr/share/tomcat7
Using CATALINA_HOME:   /usr/share/tomcat7
Using CATALINA_TMPDIR: /usr/share/tomcat7/temp
Using JRE_HOME:/usr/lib/jvm/java-7-oracle
Using CLASSPATH:
/usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar
Server version: Apache Tomcat/7.0.28
Server built:   Dec 8 2012 06:51:43
Server number:  7.0.28.0
OS Name:Linux
OS Version: 3.2.0-4-amd64
Architecture:   amd64
JVM Version:1.7.0_25-b15
JVM Vendor: Oracle Corporation

- Here's my server.xml



  
  
  
  

  




myweb.com



  


- Here's my ifconfig :
root@Debian-70-wheezy-64-minimal:/home/moonblade# ifconfig
eth0  Link encap:Ethernet  HWaddr d4:3d:7e:d8:ba:27
  inet addr:  Bcast:
 Mask:255.255.255.224
  inet6 addr: /64 Scope:Link
  inet6 addr: /64 Scope:Global
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:290094 errors:0 dropped:0 overruns:0 frame:0
  TX packets:169056 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:241176295 (230.0 MiB)  TX bytes:27580533 (26.3 MiB)
  Interrupt:43 Base address:0x6000

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:192 errors:0 dropped:0 overruns:0 frame:0
  TX packets:192 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:26625 (26.0 KiB)  TX bytes:26625 (26.0 KiB)

- no firewall, as the iptables are still empty :
root@Debian-70-wheezy-64-minimal:/home/moonblade# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

- my system
Linux Debian-70-wheezy-64-minimal 3.2.0-4-amd64 #1 SMP Debian
3.2.46-1+deb7u1 x86_64 GNU/Linux

Am i missing something in my server.xml ?


-- 
Do not pursue the past. Do not lose yourself in the future.
The past no longer is. The future has not yet come.
Looking deeply at life as it is in the very here and now,
the practitioner dwells in stability and freedom.
(Thich Nhat Hanh)