Re: Strange behavior on Tomcat 9.0.5 about ResourceLink's "name" attribute in server.xml

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Tarin,

On 3/8/18 1:56 PM, Mark Thomas wrote:
> On 08/03/18 18:53, Tarin Gamberini wrote:
>> On 08/03/2018 17:52, Rémy Maucherat wrote:
>>> On Thu, Mar 8, 2018 at 5:26 PM, Tarin Gamberini
 [cut] # PROBLEM
 
 I have two datasources in the same web application:
 
 >>> type="javax.sql.DataSource"/> >>> global="jdbc/abc/jkl/XXX_YYY" name="jdbc/abc/jkl" 
 type="javax.sql.DataSource"/> [cut]
>>> 
>>> Well, you have "abc" that s already bound and is a datasource,
>>> then you try to create a subcontext "abc" and it doesn't work.
>>> 
>> Sorry, I'm not sure I have understood what you mean. Just for
>> clarification:
>> 
>> 1. By «you have "abc" that s already bound and is a datasource»
>> are you thinking about the "abc" just after "jdbc/" in
>> «global="jdbc/abc/ABC"» ?
>> 
>> 2. By «then you try to create a subcontext "abc"» are you
>> thinking about the ending ABC in «global="jdbc/abc/ABC"» ?
> 
> No. Look at the names, not the global names.

It might help to understand a bit about how JNDI works. It's very much
like a filesystem where you have directories and files. A particular
path name can either be a file or a directory, but not both.

For example, on a standard *NIX system, you can't have a file called
/etc because there needs to be an /etc directory with files in it.

In your case, you are first creating a DataSource (the analogy here is
a file) called "jdbc/abc", and then you are trying to create another
DataSource "inside" that path "jdbc/abc" called "jdbc/abd/ABC". In
order to create "jdbc/abc/ABC", the path "jdbc/abc" must be a
directory, not a file. (In JNDI, it must be a Context, but it's a
DataSource instead).

If you were thinking that the JNDI namespace was like a map of
full-paths -> objects:

comp:env/java/jdbc/abc -> DataSource
comp:env/java/jdbc/abc/ABC -> DataSource

It doesn't work that way. Instead, the / character actually separates
parts of the hierarchy and each part has to have the expected type,
like this:

comp:env -> context
java -> context
jdbc -> context
abc -> DataSource
   [can't create a path below a DS]

Hope that helps,
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqhkqQdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFhrTg/+Ie9oIxVnXmoufSO/
vb0kRtrdhPx4KVCqVbsU9imOPpgXD6aDIxdIHs0iIFCxuQTVsJ7duIa5n9Dd3MDp
zM9E17L/wIHvGTeiuwvb6a6OWgnX1MDS9HX3UC1X9dd11DKVpWDyOeywTPiSSUn5
DWtGPyjwThVRlvX6anOUZfcNWkoGxaB/3TSyA02n6eeuhCSNLQgJJLNddwIwJTDy
/EJs2/u3HBS1KrH0aRHyPmsPEdishgbXCqj3n+AKeE6jeJvNS3VSaWbtgZ+2EHto
0f1QDSwrfOd0LEx0tv8z9TuF3cyH4F8NObnK6p9s50ogZjnjLG9kPENKe6gNznEJ
QIjzrtSr4ba8gCrmQ9hnYO40p+fiwFpCFkg2LRMmhzWHsuEfifNogud3yEmqg4+L
7s/zpL5qz0NA+LypX2mPZZq7DW893icZbncn9e/z7krQVz9gn/ETi0ejhwMBsi8n
UVlGbc9HzsUBVHD/XVMPuX3INM/ycQZHfShKK4NIp7tea/K9xQADox4yBOMzKUFM
JHZc/uPePuGAKQcN7bZkGLtVZ8Jk5sjV8uA8uayb3kWF3wRF/EdwkoebXDBArmcd
dpSJOp6u7J3QdaR63Lx9QeI1GOqzJWDrH3KGqpoOmAw4sOXBROWdAl3VtpluonTE
ri5hYpkVOQvrO5svchLr8QLn+Og=
=70hm
-END PGP SIGNATURE-

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

Re: Strange behavior on Tomcat 9.0.5 about ResourceLink's "name" attribute in server.xml

[Mark Thomas]

On 08/03/18 18:53, Tarin Gamberini wrote:
> On 08/03/2018 17:52, Rémy Maucherat wrote:
>> On Thu, Mar 8, 2018 at 5:26 PM, Tarin Gamberini
>>> [cut]
>>> # PROBLEM
>>>
>>> I have two datasources in the same web application:
>>>
>>> >> type="javax.sql.DataSource"/>
>>> >> type="javax.sql.DataSource"/>
>>> [cut]
>>
>> Well, you have "abc" that s already bound and is a datasource, then you try
>> to create a subcontext "abc" and it doesn't work. 
> Sorry, I'm not sure I have understood what you mean. Just for clarification:
> 
> 1.
> By «you have "abc" that s already bound and is a datasource» are you
> thinking about the "abc" just after "jdbc/" in «global="jdbc/abc/ABC"» ?
> 
> 2.
> By «then you try to create a subcontext "abc"» are you thinking about
> the ending ABC in «global="jdbc/abc/ABC"» ?

No. Look at the names, not the global names.

Mark

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

Re: Strange behavior on Tomcat 9.0.5 about ResourceLink's "name" attribute in server.xml

[Tarin Gamberini]

On 08/03/2018 17:52, Rémy Maucherat wrote:
> On Thu, Mar 8, 2018 at 5:26 PM, Tarin Gamberini
>> [cut]
>> # PROBLEM
>>
>> I have two datasources in the same web application:
>>
>> > type="javax.sql.DataSource"/>
>> > type="javax.sql.DataSource"/>
>>[cut]
> 
> Well, you have "abc" that s already bound and is a datasource, then you try
> to create a subcontext "abc" and it doesn't work. 
Sorry, I'm not sure I have understood what you mean. Just for clarification:

1.
By «you have "abc" that s already bound and is a datasource» are you
thinking about the "abc" just after "jdbc/" in «global="jdbc/abc/ABC"» ?

2.
By «then you try to create a subcontext "abc"» are you thinking about
the ending ABC in «global="jdbc/abc/ABC"» ?



> Try using better paths
> instead so that "abc" doesn't have to be both a subcontext and a datasource.
To get things works I have already used a different path, something like
the once tagged with "WORKS FINE" in the ending note of the original email.



Trying to rephrasing the problem: Am I wrong asking Tomcat to understand
JNDI name with subcontext for datasources, or should Tomcat accept
global/name attributes values with subcontext?

> Rémy
> 
Thank you in advance for your kind help.

Tarin
www.taringamberini.com/en/blog

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

Re: Strange behavior on Tomcat 9.0.5 about ResourceLink's "name" attribute in server.xml

[Tarin Gamberini]

On 08/03/2018 17:33, Christopher Schultz wrote:
> Tarin,
> 
> On 3/8/18 11:26 AM, Tarin Gamberini wrote:
>> ## NOTES
> 
>> The error seems realted only to ResourceLink's "name" attribute,
>> and not to "global" attribute, in server.xml:
> 
>> ERROR > type="javax.sql.DataSource"/> > global="jdbc/abc/jkl/XXX_YYY" name="jdbc/abc/jkl" 
>> type="javax.sql.DataSource"/>
> 
>> The error disappears with the following "name" attribute values (of
>> course when I change the "name" attribute value I change
>> accordingly the "" tag body in the web.xml):
> 
>> WORKS FINE > type="javax.sql.DataSource"/> > global="jdbc/abc/jkl/XXX_YYY" name="jdbc/abx/jkl" 
>> type="javax.sql.DataSource"/>
> 
> This looks like exactly the same as above (except for the likely type
> of 'x' -> 'c' in the second config). Am I missing something?
That's right, they differ only from a single character.

> -chris
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
Kind regards,
Tarin
www.taringamberini.com/en/blog

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

Re: Strange behavior on Tomcat 9.0.5 about ResourceLink's "name" attribute in server.xml

[Rémy Maucherat]

On Thu, Mar 8, 2018 at 5:26 PM, Tarin Gamberini 
wrote:

> Hi everybody,
>
> I have found a strange behavior on Tomcat 9.0.5 (originally on Tomcat
> 8.5.28).
>
>
> # PROBLEM
>
> I have two datasources in the same web application:
>
>  type="javax.sql.DataSource"/>
>  type="javax.sql.DataSource"/>
>
> Starting the server I get an "java.lang.ClassCastException:
> org.apache.tomcat.dbcp.dbcp2.BasicDataSource cannot be cast to
> javax.naming.Context" ERROR.
>

Well, you have "abc" that s already bound and is a datasource, then you try
to create a subcontext "abc" and it doesn't work. Try using better paths
instead so that "abc" doesn't have to be both a subcontext and a datasource.

Rémy

Re: WebApp Caching Broken

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ken,

On 3/8/18 11:31 AM, Kenneth Taylor wrote:
> To clarify: We were making changes to our webapp and re-deploying
> and the changes were not showing up.  We think this was happening
> because of the shutdown problem I stated earlier.  There was more
> than one Tomcat running.  Also, there were some configuration
> issues that could have contributed to the problem, maybe, and it is
> also possible that our build system picked up an old config file
> that had the unpackWars flag set to false.  My use of the "caching"
> was simply a way of describing this problem.

Definitely make sure Tomcat is stopped. You can use the "jps" program
on most platforms to see what JVMs are running. The Tomcat processes
show with the name "Bootstrap" if you are using a traditional
(non-embedded) Tomcat.

> Also that JVM flag is supposed to disable connecting via a
> debugger, or any other application that uses the JVM Attach
> mechanism.  If that flag is not set then anyone who has network
> access can connect to any webapp in Tomcat, say with a debugger,
> and access sensitive information.

You have to have "host" access, not just network access. The Attach
API does not bind to any ports. Also, you either have to be the owner
of the process or have administrative access. For example, on a shared
server, I can't run "jstack -F [other users pid]" and get a thread
dump from their Java process. I can do it if I use "sudo", though.

Perhaps you are thinking of JMX? That requires a special
configuration, and *can* allow network access (though it's a real pain
IMO).

> If you run any JVM directly, with that flag set, you will not be
> able to connect to it, even if a debugger is configured. So if its
> not working with Tomcat then it is a potential security problem.

It does work. I just fired-up a Tomcat instance with that flag set on
the JVM:

$ $CATALINA_HOME/bin/catalina.sh start
$ jps
14491 Bootstrap
$ jstack 14491
14491: The VM does not support the attach mechanism
The -F option can be used when the target process is not responding
$ jstack -F 14491
Attaching to process ID 14491, please wait...
Error attaching to process:
sun.jvm.hotspot.debugger.DebuggerException: Can't attach symbolicator
to the process
sun.jvm.hotspot.debugger.DebuggerException:
sun.jvm.hotspot.debugger.DebuggerException: Can't attach symbolicator
to the process
at
sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal$BsdDebuggerLocalWorkerThre
ad.execute(BsdDebuggerLocal.java:169)
at
sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.attach(BsdDebuggerLocal.ja
va:287)
at sun.jvm.hotspot.HotSpotAgent.attachDebugger(HotSpotAgent.java:671)
at
sun.jvm.hotspot.HotSpotAgent.setupDebuggerDarwin(HotSpotAgent.java:659)
at sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:341)
at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:304)
at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:140)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:185)
at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
at sun.jvm.hotspot.tools.JStack.main(JStack.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.tools.jstack.JStack.runJStackTool(JStack.java:140)
at sun.tools.jstack.JStack.main(JStack.java:106)
Caused by: sun.jvm.hotspot.debugger.DebuggerException: Can't attach
symbolicator to the process
at sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.attach0(Native Method)
at
sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.access$100(BsdDebuggerLoca
l.java:65)
at
sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal$1AttachTask.doit(BsdDebugg
erLocal.java:278)
at
sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal$BsdDebuggerLocalWorkerThre
ad.run(BsdDebuggerLocal.java:144)

> Re-producing it is easy.  Simply set the flag and then run Tomcat
> and then connect with a debugger.
How are you setting that flag?

> Of course to use a debugger you also have to configure it in the 
> properties you start Tomcat with, but some JVM Attach apps may
> work without requiring that.
So... you are specifically configuring your JVM to allow debugging,
and you are upset that you can attach a debugger?

Are you sure the "attach" API is being used, here?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqhaaYdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjb1A/5Ad7eIPM1uLWjWt9O
naBVW0PJ2Y7wC3VDxmBbOB4Ya1/7wLwmcti5ltIWQ5ZvRmUMPVzwlewRo7P4hcZV
AqWKftcNQQW9OnVR9M+0Bgt/2te2vYyirFHIxRffW4w7uLkM5nOn0pryktm2zHpx

Re: Strange behavior on Tomcat 9.0.5 about ResourceLink's "name" attribute in server.xml

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Tarin,

On 3/8/18 11:26 AM, Tarin Gamberini wrote:
> ## NOTES
> 
> The error seems realted only to ResourceLink's "name" attribute,
> and not to "global" attribute, in server.xml:
> 
> ERROR  type="javax.sql.DataSource"/>  global="jdbc/abc/jkl/XXX_YYY" name="jdbc/abc/jkl" 
> type="javax.sql.DataSource"/>
> 
> The error disappears with the following "name" attribute values (of
> course when I change the "name" attribute value I change
> accordingly the "" tag body in the web.xml):
> 
> WORKS FINE  type="javax.sql.DataSource"/>  global="jdbc/abc/jkl/XXX_YYY" name="jdbc/abx/jkl" 
> type="javax.sql.DataSource"/>

This looks like exactly the same as above (except for the likely type
of 'x' -> 'c' in the second config). Am I missing something?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqhZeQdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFhsbg/+K7BIB3uSvj6UUq4+
HhebXBiSbrbw769wUK9YAmaLYsXU43TswRI5g05pSOZ6jQx4sR/z+GU6zPbeLapP
fC10BlzU3fPsHLWBZKb2pDisTcPS6uK/ByI30nqf2wESRmY3CJTyaGuEVfGYQ+Gg
Zb07KMEMVtEIFZaULhUrlLqgxBQ9kNC8jjutAQiEqArKa7LvdwuKQ66brwvSQMbL
c1Y4d+3cmYl78rLPrX82K4evwfWKheB1TYzA+oDmjYSJj95s3KWn1p2VEKH3bUG4
BJADrOweOvVv1IcrzcyCzArTqsntAickPZz/gLi5r1SaULggHoWs7Ci2dp6osynP
G+Wnj86DeIpA2eyK16vaZPPKTOLq5z5mfNKroF1d/L2vb0v/WpbYXk6bQpM3HFW4
zR8S3vFYuRHq8ES/Vubs9qhAmZtdJGK9HqTMCsLISZ2EKtsjlJApmFMA41iAknHw
jamg/uYT2FV8synobGU9Ikht5fMTg14NaQ0uztXEIO20YiP22bTvstYERqx35iUZ
nVs8eYoWEjlekbInHTXBdZ15AAN1TvAEqWQUX81WKRN4Jdqc1XoTMPSp8SELRpAw
US/4eUowux13KnKxfPkG54kDo454K5OATYVAZO5zrNYeIU7eVHXYT+05+e0jXIoC
fihQasr9cTp9P/IjTsQ2Ujd8bZU=
=+Iam
-END PGP SIGNATURE-

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

RE: WebApp Caching Broken

[Kenneth Taylor]

Thanks for the pointers.  I did not realize that I had setup Tomcat emails to 
go to a folder and didn't see people's responses.  Sorry about that.

To clarify: We were making changes to our webapp and re-deploying and the 
changes were not showing up.  We think this was happening because of the 
shutdown problem I stated earlier.  There was more than one Tomcat running.  
Also, there were some configuration issues that could have contributed to the 
problem, maybe, and it is also possible that our build system picked up an old 
config file that had the unpackWars flag set to false.  My use of the "caching" 
was simply a way of describing this problem.

Also that JVM flag is supposed to disable connecting via a debugger, or any 
other application that uses the JVM Attach mechanism.  If that flag is not set 
then anyone who has network access can connect to any webapp in Tomcat, say 
with a debugger, and access sensitive information.  If you run any JVM 
directly, with that flag set, you will not be able to connect to it, even if a 
debugger is configured.  So if its not working with Tomcat then it is a 
potential security problem.  Re-producing it is easy.  Simply set the flag and 
then run Tomcat and then connect with a debugger.  Of course to use a debugger 
you also have to configure it in the properties you start Tomcat with, but some 
JVM Attach apps may work without requiring that.

Thanks.
Ken

Disclaimer: This email from DMBGroup LLC, DMB Consulting Services LLC, or the 
personnel associated with either entity (collectively "DMB") and attachments, 
contain CONFIDENTIAL, PRIVILEGED AND PROPRIETARY information for exclusive use 
of the addressee individual(s) or entity. Unauthorized viewing, copying, 
disclosure, distribution or use of this e-mail or attachments may be subject to 
legal restriction or sanction. If received in error, notify sender immediately 
by return e-mail and delete original message and attachments. Nothing contained 
in this e-mail or attachments shall satisfy the requirements for a writing 
unless specifically stated. Nothing contained herein shall constitute a 
contract or electronic signature under the Electronic Signatures in Global and 
National Commerce Act, any version of the Uniform Electronic Transactions Act 
or any other statute governing electronic transactions. Opinions and statements 
expressed in this e-mail and any attachments are those of the individual sender 
and not necessarily of DMB. DMB does not guarantee this e-mail transmission is 
secured, error or virus-free. Neither DMB nor the sender of this e-mail accepts 
liability for errors or omissions in the contents of this e-mail, which arise 
as a result of e-mail transmission. .



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

Strange behavior on Tomcat 9.0.5 about ResourceLink's "name" attribute in server.xml

[Tarin Gamberini]

Hi everybody,

I have found a strange behavior on Tomcat 9.0.5 (originally on Tomcat
8.5.28).


# PROBLEM

I have two datasources in the same web application:




Starting the server I get an "java.lang.ClassCastException:
org.apache.tomcat.dbcp.dbcp2.BasicDataSource cannot be cast to
javax.naming.Context" ERROR.



# HOW TO REPRODUCE THE ERROR

In my Apache Tomcat 9.0.5's server.xml:






In C:\my-favourite-ide\abc\src\main\webapp\META-INF\context.xml (it's an
Apache Maven project):








In C:\my-favourite-ide\abc\src\main\webapp\WEB-INF\web.xml:


Datasource ofv
jdbc/abc
javax.sql.DataSource
Container


Datasource ofv
jdbc/abc/jkl
javax.sql.DataSource
Container


Starting the server I get the "java.lang.ClassCastException:
org.apache.tomcat.dbcp.dbcp2.BasicDataSource cannot be cast to
javax.naming.Context" ERROR:

Using CATALINA_BASE:   "C:\java\apache-tomcat-9.0.5-catalina-base"
Using CATALINA_HOME:   "C:\java\apache-tomcat-9.0.5"
Using CATALINA_TMPDIR: "C:\java\apache-tomcat-9.0.5-catalina-base\temp"
Using JRE_HOME:"C:\java\jdk1.8.0_111"
Using CLASSPATH:
 
"C:\java\apache-tomcat-9.0.5\bin\bootstrap.jar;C:\java\apache-tomcat-9.0.5\bin\tomcat-juli.jar"
06-Mar-2018 10:23:07.968 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log Server version:
  Apache Tomcat/9.0.5
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log Server built:
  Feb 6 2018 21:42:23 UTC
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log Server number:
 9.0.5.0
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log OS Name:
 Windows 7
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log OS Version:
  6.1
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log Architecture:
  amd64
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log Java Home:
 C:\java\jdk1.8.0_111\jre
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log JVM Version:
 1.8.0_111-b14
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:
  Oracle Corporation
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE:
 C:\java\apache-tomcat-9.0.5-catalina-base
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME:
 C:\java\apache-tomcat-9.0.5
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument:
-Djava.util.logging.config.file=C:\java\apache-tomcat-9.0.5-catalina-base\conf\logging.properties
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Djdk.tls.ephemeralDHKeySize=2048
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Dignore.endorsed.dirs=
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Dcatalina.base=C:\java\apache-tomcat-9.0.5-catalina-base
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Dcatalina.home=C:\java\apache-tomcat-9.0.5
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Djava.io.tmpdir=C:\java\apache-tomcat-9.0.5-catalina-base\temp
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR
based Apache Tomcat Native library [1.2.16] using APR version [1.6.3].
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
capabilities: IPv6 [true], sendfile [true], accept filters [false], random
[true].
06-Mar-2018 10:23:07.984 WARN [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL
configuration: useAprConnector [false], useOpenSSL [true]
06-Mar-2018 10:23:08.545 WARN [main]
org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL
successfully initialized [OpenSSL 1.0.2m  2 Nov 2017]
06-Mar-2018 10:23:08.920 WARN [main]
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["http-nio-8080"]
06-Mar-2018 10:23:08.966 WARN [main]
org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared
selector