Re: Run servlets on Nashorn written in server-side JavaScript
Hi Leo, why would you want to do that if you could do the same with Java? What is the motivation, the use case for you? How urgent is this (I may have something for both, Java EE and Jakarta EE, but need a little bit of time)? —-rony On 15.02.2021 07:29, leo wrote: > Hi there > > I am trying to find out how to process servlets written in server-side > JavaScript through Tomcat. > > I looked through the Tomcat FAQ and How-To but couldn't find anything. By > googling I found a way > to hook up Python through Jython's PyServlet class. I tried this and it works > great. > > But I am looking for server-side JavaScript in Tomcat. I am aware of the > JavaScript engine > Nashorn. Is there a way to hook up Nashorn with a servlet class, so that > Tomcat serves JavaScript > servlets? Something like a "JavaScript Server Page" for Tomcat would be fine > too. > > Many thanks for any pointers, > Leo > > ps: I use Tomcat 8.5, but I could move to another Tomcat version for this. > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: embedded, not local
Other than the browsers not trusting my self-signed cert I think I'm now in the business of impersonation AWS ;) Thanks to all I've bothered, rjs On 2/16/21 7:50 PM, Rob Sargent wrote: Ah, yes, a stray Constuctor() left lying around. Thank you! I am now down to dealing with https mis-configurations, which puts me squarely back to the future. Ever grateful, rjs On 2/16/21 3:27 PM, Mark Thomas wrote: On February 16, 2021 10:00:01 PM UTC, Noelette Stout wrote: I'm kinda new to this, but it looks like you're trying to start http and https on the same port. Feb 16, 2021 1:06:59 PM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["http-nio-16004"] Feb 16, 2021 1:06:59 PM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["https-jsse-nio-16004"] In my (admittedly limited) experience, they need to be on separate ports. +1. That is clearly the problem given those log messages. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: embedded, not local
Ah, yes, a stray Constuctor() left lying around. Thank you! I am now down to dealing with https mis-configurations, which puts me squarely back to the future. Ever grateful, rjs On 2/16/21 3:27 PM, Mark Thomas wrote: On February 16, 2021 10:00:01 PM UTC, Noelette Stout wrote: I'm kinda new to this, but it looks like you're trying to start http and https on the same port. Feb 16, 2021 1:06:59 PM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["http-nio-16004"] Feb 16, 2021 1:06:59 PM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["https-jsse-nio-16004"] In my (admittedly limited) experience, they need to be on separate ports. +1. That is clearly the problem given those log messages. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: embedded, not local
On February 16, 2021 10:00:01 PM UTC, Noelette Stout wrote: >I'm kinda new to this, but it looks like you're trying to start http >and >https on the same port. > >Feb 16, 2021 1:06:59 PM org.apache.coyote.AbstractProtocol init >INFO: Initializing ProtocolHandler ["http-nio-16004"] >Feb 16, 2021 1:06:59 PM org.apache.coyote.AbstractProtocol init >INFO: Initializing ProtocolHandler ["https-jsse-nio-16004"] > >In my (admittedly limited) experience, they need to be on separate >ports. +1. That is clearly the problem given those log messages. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: embedded, not local
I'm kinda new to this, but it looks like you're trying to start http and https on the same port. Feb 16, 2021 1:06:59 PM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["http-nio-16004"] Feb 16, 2021 1:06:59 PM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["https-jsse-nio-16004"] In my (admittedly limited) experience, they need to be on separate ports. just my 2 cents On Tue, Feb 16, 2021 at 2:39 PM Rob Sargent wrote: > change port assignment (16005) and restarted server. port in use. > > > On 2/16/21 2:36 PM, Rob Sargent wrote: > > Rebooted desktop k1. I get port in use first time I start my server > > (shell). > > > > > > On 2/16/21 1:26 PM, Christopher Schultz wrote: > >> Rob, > >> > >> On 2/16/21 15:02, Rob Sargent wrote: > >>> The logging so far has told me only that my port 16004 is in use, > >>> but at outset it clearly is not according to netstat or ss. Is > >>> tomcat opening that port before the call to "tomcat.start(); > >>> tomcat.getServer().await():"? > >> > >> It it says "port in use" then first stop your application, then make > >> sure all other processes that may have bound that port are stopped. > >> Maybe it's been failing because you have effectively been changing > >> nothing (because some older process is still holding onto the port). > >> > >> -chris > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > > > > > > -- Noelette Stout ITS Enterprise Applications - Application Administrator - Senior Business Administration Building, Rm 109L 921 South 8th Ave 8037 Idaho State University Pocatello ID 83209 E-mail: stounoel "at" isu "dot" edu Desk: 208-282-2554
Re: embedded, not local
change port assignment (16005) and restarted server. port in use. On 2/16/21 2:36 PM, Rob Sargent wrote: Rebooted desktop k1. I get port in use first time I start my server (shell). On 2/16/21 1:26 PM, Christopher Schultz wrote: Rob, On 2/16/21 15:02, Rob Sargent wrote: The logging so far has told me only that my port 16004 is in use, but at outset it clearly is not according to netstat or ss. Is tomcat opening that port before the call to "tomcat.start(); tomcat.getServer().await():"? It it says "port in use" then first stop your application, then make sure all other processes that may have bound that port are stopped. Maybe it's been failing because you have effectively been changing nothing (because some older process is still holding onto the port). -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: embedded, not local
Rebooted desktop k1. I get port in use first time I start my server (shell). On 2/16/21 1:26 PM, Christopher Schultz wrote: Rob, On 2/16/21 15:02, Rob Sargent wrote: The logging so far has told me only that my port 16004 is in use, but at outset it clearly is not according to netstat or ss. Is tomcat opening that port before the call to "tomcat.start(); tomcat.getServer().await():"? It it says "port in use" then first stop your application, then make sure all other processes that may have bound that port are stopped. Maybe it's been failing because you have effectively been changing nothing (because some older process is still holding onto the port). -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: embedded, not local
Rob, On 2/16/21 15:02, Rob Sargent wrote: The logging so far has told me only that my port 16004 is in use, but at outset it clearly is not according to netstat or ss. Is tomcat opening that port before the call to "tomcat.start(); tomcat.getServer().await():"? It it says "port in use" then first stop your application, then make sure all other processes that may have bound that port are stopped. Maybe it's been failing because you have effectively been changing nothing (because some older process is still holding onto the port). -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: embedded, not local
Sorry, meant to show the log: Feb 16, 2021 1:06:59 PM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["http-nio-16004"] Feb 16, 2021 1:06:59 PM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["https-jsse-nio-16004"] Feb 16, 2021 1:06:59 PM org.apache.catalina.util.LifecycleBase handleSubClassException SEVERE: Failed to initialize component [Connector[HTTP/1.1-16004]] org.apache.catalina.LifecycleException: Protocol handler initialization failed at org.apache.catalina.connector.Connector.initInternal(Connector.java:1049) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:558) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1045) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:173) at org.apache.catalina.startup.Tomcat.start(Tomcat.java:486) ===> at edu.utah.camplab.server.SGSSelector.kickOff(SGSSelector.java:172) at edu.utah.camplab.server.SGSSelector.run(SGSSelector.java:184) at java.base/java.lang.Thread.run(Thread.java:832) Caused by: java.net.BindException: Address already in use at java.base/sun.nio.ch.Net.bind0(Native Method) at java.base/sun.nio.ch.Net.bind(Net.java:550) at java.base/sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:249) at org.apache.tomcat.util.net.NioEndpoint.initServerSocket(NioEndpoint.java:277) at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:241) at org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1193) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1206) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:597) at org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:80) at org.apache.catalina.connector.Connector.initInternal(Connector.java:1046) ... 10 more ===> embeddedTomcat.start(); On 2/16/21 1:02 PM, Rob Sargent wrote: The logging so far has told me only that my port 16004 is in use, but at outset it clearly is not according to netstat or ss. Is tomcat opening that port before the call to "tomcat.start(); tomcat.getServer().await():"? On 2/16/21 12:04 PM, Rob Sargent wrote: I'm managed to open the flood gates. Will report soon.
Re: embedded, not local
The logging so far has told me only that my port 16004 is in use, but at outset it clearly is not according to netstat or ss. Is tomcat opening that port before the call to "tomcat.start(); tomcat.getServer().await():"? On 2/16/21 12:04 PM, Rob Sargent wrote: I'm managed to open the flood gates. Will report soon.
Re: embedded, not local
I'm managed to open the flood gates. Will report soon. On 2/16/21 11:25 AM, Rob Sargent wrote: Thanks, Chris, Complete radio silence when running from command line [1][2] with a startup script and running in IntelliJ [3]. (I wish I could make the same /mistake/ with jOOQ;) ) I have managed to get access-logging started. The only warning I get (cmdline) is from the jvm WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.apache.catalina.loader.WebappClassLoaderBase (file:/home/u0138544/.gradle/caches/modules-2/files-2.1/org.apache.tomcat.embed/tomcat-embed-core/9.0.43/1d102277426bdd5b12f048731a91665bb69347d1/tomcat-embed-core-9.0.43.jar) to field java.io.ObjectStreamClass$Caches.localDescs WARNING: Please consider reporting this to the maintainers of org.apache.catalina.loader.WebappClassLoaderBase WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release but I'm sure that's not news. I use logback in my main app import org.slf4j.Logger; import org.slf4j.LoggerFactory; private final static Logger logger = LoggerFactory.getLogger(SGSSelector.class); I actually have storeType set to PCKS12. I had also tried JKS and edited that out in the emial. Very sorry for the sloppiness - Paused to check CK v. KC. No noise from setting it to JKS. [1] My start-up script #!/bin/bash -e export CATALINA_HOME=$HOME/aws/deploy/webroot/ export CATALINA_BASE=$CATALINA_HOME export SGSWEBDIR=$CATALINA_HOME/tomcat.16004/work/Tomcat/kispiox.hci.utah.edu if [[ "$1"x == "x" ]] then if [[ ! -e $$SGSWEBDIR ]] then mkdir -p $SGSWEBDIR/sgs else echo clean out sgs app rm -rf $SGSWEBDIR/sgs fi cp /home/u0138544/gits/java/gitlab/gtdb/webapp/build/libs/sgs-1.0.war $SGSWEBDIR/sgs/sgs.war cd $SGSWEBDIR/sgs jar -xf sgs.war cd $CATALINA_BASE sed -i -f $HOME/aws/deploy/bin/context.sed $SGSWEBDIR/sgs/META-INF/context.xml > $SGSWEBDIR/sgs/META-INF/context.xml awk -f ~/aws/deploy/bin/webxml.awk --assign=PILIST="$1" $HOME/aws/deploy/bin/context.sed $SGSWEBDIR/sgs/WEB-INF/web.xml > $SGSWEBDIR/sgs/WEB-INF/web.xml.pi mv $SGSWEBDIR/sgs/WEB-INF/web.xml.pi $SGSWEBDIR/sgs/WEB-INF/web.xml fi . $HOME/aws/deploy/bin/cp4.sh cd $CATALINA_BASE java --enable-preview edu.utah.camplab.server.SGSSelector $HOME/aws/deploy/bin/selector.properties [2] My classpath, very much in dev-land, pointing to working trees (mains) and such to match gradle tasks export CLASSPATH=\ /home/u0138544/gits/java/gitlab/gtdb/sgsaas/build/classes/java/main:\ /home/u0138544/gits/java/gitlab/gtdb/transport/build/classes/java/main:\ /home/u0138544/gits/java/gitlab/gtdb/tools/build/classes/java/main:\ /home/u0138544/gits/java/gitlab/gtdb/jooq/build/classes/java/main:\ /home/u0138544/gits/java/gitlab/gtdb/anno/build/classes/java/main:\ /home/u0138544/.m2/repository/org/slf4j/slf4j-api/1.7.7/slf4j-api-1.7.7.jar:\ /home/u0138544/.m2/repository/jpsgcs/jpsgcs/3.2.1-2/jpsgcs-3.2.1-2.jar:\ /home/u0138544/.m2/repository/commons-logging/commons-logging/1.2/commons-logging-1.2.jar:\ /home/u0138544/.m2/repository/com/jonoler/longpowerset/longpowerset/1.0/longpowerset-1.0.jar:\ /home/u0138544/.m2/repository/ch/qos/logback/logback-core/1.1.2/logback-core-1.1.2.jar:\ /home/u0138544/.m2/repository/ch/qos/logback/logback-classic/1.1.2/logback-classic-1.1.2.jar:\ /home/u0138544/.m2/repository/ch/qos/logback/logback-access/1.1.2/logback-access-1.1.2.jar:\ /home/u0138544/.gradle/caches/modules-2/files-2.1/software.amazon.ion/ion-java/1.0.2/ee9dacea7726e495f8352b81c12c23834ffbc564/ion-java-1.0.2.jar:\ /home/u0138544/.gradle/caches/modules-2/files-2.1/org.reactivestreams/reactive-streams/1.0.2/323964c36556eb0e6209f65c1cef72b53b461ab8/reactive-streams-1.0.2.jar:\ /home/u0138544/.gradle/caches/modules-2/files-2.1/org.postgresql/postgresql/42.2.18/a0a9c1d43c7727eeaf1b729477891185d3c71751/postgresql-42.2.18.jar:\ /home/u0138544/.gradle/caches/modules-2/files-2.1/org.jooq/jooq/3.14.7/46dd951bc6607d32c249bf3fea36038754c38905/jooq-3.14.7.jar:\ /home/u0138544/.gradle/caches/modules-2/files-2.1/org.jooq/jooq-meta/3.14.7/641e452aaa99ba24feec658147d81d4be7a11c90/jooq-meta-3.14.7.jar:\ /home/u0138544/.gradle/caches/modules-2/files-2.1/org.jooq/jooq-codegen/3.14.7/982bafbd5edf574bed4aab98ca7176c7e84d729/jooq-codegen-3.14.7.jar:\ /home/u0138544/.gradle/caches/modules-2/files-2.1/org.eclipse.jdt/ecj/3.18.0/4d5d0911b30db24c8eb844702c8adf8e434314ff/ecj-3.18.0.jar:\ /home/u0138544/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-all/2.4.7/c5371aaa20bcdca1175d9477fc0811f4fd99b68a/groovy-all-2.4.7.jar:\
Re: embedded, not local
Thanks, Chris, Complete radio silence when running from command line [1][2] with a startup script and running in IntelliJ [3]. (I wish I could make the same /mistake/ with jOOQ;) ) I have managed to get access-logging started. The only warning I get (cmdline) is from the jvm WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.apache.catalina.loader.WebappClassLoaderBase (file:/home/u0138544/.gradle/caches/modules-2/files-2.1/org.apache.tomcat.embed/tomcat-embed-core/9.0.43/1d102277426bdd5b12f048731a91665bb69347d1/tomcat-embed-core-9.0.43.jar) to field java.io.ObjectStreamClass$Caches.localDescs WARNING: Please consider reporting this to the maintainers of org.apache.catalina.loader.WebappClassLoaderBase WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release but I'm sure that's not news. I use logback in my main app import org.slf4j.Logger; import org.slf4j.LoggerFactory; private final static Logger logger = LoggerFactory.getLogger(SGSSelector.class); I actually have storeType set to PCKS12. I had also tried JKS and edited that out in the emial. Very sorry for the sloppiness - Paused to check CK v. KC. No noise from setting it to JKS. [1] My start-up script #!/bin/bash -e export CATALINA_HOME=$HOME/aws/deploy/webroot/ export CATALINA_BASE=$CATALINA_HOME export SGSWEBDIR=$CATALINA_HOME/tomcat.16004/work/Tomcat/kispiox.hci.utah.edu if [[ "$1"x == "x" ]] then if [[ ! -e $$SGSWEBDIR ]] then mkdir -p $SGSWEBDIR/sgs else echo clean out sgs app rm -rf $SGSWEBDIR/sgs fi cp /home/u0138544/gits/java/gitlab/gtdb/webapp/build/libs/sgs-1.0.war $SGSWEBDIR/sgs/sgs.war cd $SGSWEBDIR/sgs jar -xf sgs.war cd $CATALINA_BASE sed -i -f $HOME/aws/deploy/bin/context.sed $SGSWEBDIR/sgs/META-INF/context.xml > $SGSWEBDIR/sgs/META-INF/context.xml awk -f ~/aws/deploy/bin/webxml.awk --assign=PILIST="$1" $HOME/aws/deploy/bin/context.sed $SGSWEBDIR/sgs/WEB-INF/web.xml > $SGSWEBDIR/sgs/WEB-INF/web.xml.pi mv $SGSWEBDIR/sgs/WEB-INF/web.xml.pi $SGSWEBDIR/sgs/WEB-INF/web.xml fi . $HOME/aws/deploy/bin/cp4.sh cd $CATALINA_BASE java --enable-preview edu.utah.camplab.server.SGSSelector $HOME/aws/deploy/bin/selector.properties [2] My classpath, very much in dev-land, pointing to working trees (mains) and such to match gradle tasks export CLASSPATH=\ /home/u0138544/gits/java/gitlab/gtdb/sgsaas/build/classes/java/main:\ /home/u0138544/gits/java/gitlab/gtdb/transport/build/classes/java/main:\ /home/u0138544/gits/java/gitlab/gtdb/tools/build/classes/java/main:\ /home/u0138544/gits/java/gitlab/gtdb/jooq/build/classes/java/main:\ /home/u0138544/gits/java/gitlab/gtdb/anno/build/classes/java/main:\ /home/u0138544/.m2/repository/org/slf4j/slf4j-api/1.7.7/slf4j-api-1.7.7.jar:\ /home/u0138544/.m2/repository/jpsgcs/jpsgcs/3.2.1-2/jpsgcs-3.2.1-2.jar:\ /home/u0138544/.m2/repository/commons-logging/commons-logging/1.2/commons-logging-1.2.jar:\ /home/u0138544/.m2/repository/com/jonoler/longpowerset/longpowerset/1.0/longpowerset-1.0.jar:\ /home/u0138544/.m2/repository/ch/qos/logback/logback-core/1.1.2/logback-core-1.1.2.jar:\ /home/u0138544/.m2/repository/ch/qos/logback/logback-classic/1.1.2/logback-classic-1.1.2.jar:\ /home/u0138544/.m2/repository/ch/qos/logback/logback-access/1.1.2/logback-access-1.1.2.jar:\ /home/u0138544/.gradle/caches/modules-2/files-2.1/software.amazon.ion/ion-java/1.0.2/ee9dacea7726e495f8352b81c12c23834ffbc564/ion-java-1.0.2.jar:\ /home/u0138544/.gradle/caches/modules-2/files-2.1/org.reactivestreams/reactive-streams/1.0.2/323964c36556eb0e6209f65c1cef72b53b461ab8/reactive-streams-1.0.2.jar:\ /home/u0138544/.gradle/caches/modules-2/files-2.1/org.postgresql/postgresql/42.2.18/a0a9c1d43c7727eeaf1b729477891185d3c71751/postgresql-42.2.18.jar:\ /home/u0138544/.gradle/caches/modules-2/files-2.1/org.jooq/jooq/3.14.7/46dd951bc6607d32c249bf3fea36038754c38905/jooq-3.14.7.jar:\ /home/u0138544/.gradle/caches/modules-2/files-2.1/org.jooq/jooq-meta/3.14.7/641e452aaa99ba24feec658147d81d4be7a11c90/jooq-meta-3.14.7.jar:\ /home/u0138544/.gradle/caches/modules-2/files-2.1/org.jooq/jooq-codegen/3.14.7/982bafbd5edf574bed4aab98ca7176c7e84d729/jooq-codegen-3.14.7.jar:\ /home/u0138544/.gradle/caches/modules-2/files-2.1/org.eclipse.jdt/ecj/3.18.0/4d5d0911b30db24c8eb844702c8adf8e434314ff/ecj-3.18.0.jar:\ /home/u0138544/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-all/2.4.7/c5371aaa20bcdca1175d9477fc0811f4fd99b68a/groovy-all-2.4.7.jar:\
Re: embedded, not local
Rob,
On 2/15/21 18:26, Rob Sargent wrote:
Thanks again, Chris,
On 2/15/21 1:32 PM, Christopher Schultz wrote:
Try this:
$ openssl s_client -showcerts -connect k1:16004 -tls1_2
openssl s_client -showcerts -connect k1:16004 -tls1_2
CONNECTED(0003)
140444510528832:error:1408F10B:SSL routines:ssl3_get_record:wrong
version number:../ssl/record/ssl3_record.c:331:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 217 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher :
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1613429202
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
Check the port? Remember that TLS is enabled on one port (Connector)
while plaintext is on another port (Connector). So switch from
plaintext to TLS you will need to change port numbers in your s_client
connection string (and browser).
How many connectors are you configuring? And how? Your code only shows
configuring a local "connector" reference, but not where it came from,
if it was added to the server component, etc.
I'm not following perfectly. I did localhost lookup at Luis's
suggestion, but I name k1 in all my code/runs.
Do I have to add a doOptions handler in my servlets to handle prefight?
This is my Connector generation and consumption code:
Service service = embeddedTomcat.getService();
service.addConnector(addTLSConnector(tomcatPort));
private Connector addTLSConnector(int tcport) {
Connector connector = new Connector();
addTLSConnector(connector, tcport);
return connector;
}
private Connector addTLSConnector(Connector connector, int tcport) {
File keyFile = new File
(System.getProperty("SGSSRVR_keystoreFile"));
if (! keyFile.exists()) throw new RuntimeException("where's the
keystore?");
File trustFile = new File
(System.getProperty("SGSSRVR_truststoreFile"));
if (! trustFile.exists()) throw new RuntimeException("where's
the truststore?");
boolean done = true;
connector.setPort(tcport);
connector.setSecure(true);
connector.setScheme(System.getProperty("SGSSRVR_scheme"));
//done = done && connector.setProperty("protocol", "HTTP/1.1");
done = done && connector.setProperty("sslProtocol", "TLS");
done = done &&
connector.setProperty("address",System.getProperty("SGSSRVR_hostaddr"));
done = done && connector.setProperty("keyAlias",
System.getProperty("SGSSRVR_keystoreAlias"));
done = done && connector.setProperty("keystorePass",
System.getProperty("SGSSRVR_keystorePwd"));
done = done && connector.setProperty("keystoreFile",
keyFile.getAbsolutePath());
done = done && connector.setProperty("keystoreType",
System.getProperty("SGSSRVR_storeType"));
// done = done && connector.setProperty("truststoreType",
System.getProperty("SGSSRVR_storeType"));
// done = done && connector.setProperty("truststoreFile",
trustFile.getAbsolutePath());
// done = done && connector.setProperty("truststoreAlias",
System.getProperty("SGSSRVR_truststoreAlias"));
// done = done && connector.setProperty("truststorePassword",
System.getProperty("SGSSRVR_truststorePwd"));
done = done && connector.setProperty("clientAuth", "false");
done = done && connector.setProperty("maxThreads", "200");
done = done && connector.setProperty("SSLEnabled", "true");
if (! done) {
System.out.println("Some problem(s) in connector setup");
}
return connector;
}
with comments on trust or key lines or neither. trust.Alias and
trust.pass, in either order, always fail (seen in IntelliJ when 'done'
flips to false)
and the properties are sent in from files:
SGSSRVR_socketPort = 16004
SGSSRVR_scheme = https
SGSSRVR_databaseConnection = jdbc:postgresql://%s:%d/%s
SGSSRVR_emergencyJsonDir = /home/u0138544/aws/deploy/crash/
SGSSRVR_ContextRootDir =
/home/u0138544/aws/deploy/webroot/tomcat.16004/work/Tomcat/k1
SGSSRVR_dbTestUser = viv
SGSSRVR_dbTestDb = postgres
SGSSRVR_databasePort = 5432
SGSSRVR_databaseHost = k2
SGSSRVR_roleExtension = _notnull
SGSSRVR_expansionStep = 5
SGSSRVR_hostaddr = k1
SGSSRVR_keystoreFile = /home/u0138544/aws/deploy/server/k1.p12
SGSSRVR_keystoreAlias = k1
SGSSRVR_keystorePwd = changeit
SGSSRVR_truststoreFile =
Standards, specs for URL parameter ordering
All, I'm sorry for using users@ as my own personal Google but I'm sure someone knows this off the top of their head and can save me a lot of reading. I'm wondering about which specs mention how to handle URL parameters (and POST parameters, for that matter) in terms of ordering. For example, if I have a URL like: https://example.com/context/resource?a=1=2=3=6 (Note that I have "a" in there twice) If I call request.getParameterNames(), is there a predictable order in which those parameters will be handed back? I'd love to hear that not only are they returned in "URL order" (that is, the left-most parameter is the first returned in that enumeration) in Tomcat, but either the servlet spec, the CGI spec, or some other spec dictates that order explicitly. Similarly, if I use request.getParameterMap and than iterate through the keys or Map.Entry objects in it, does that behave predictably as well? I have a situation where both URL parameters and POST parameters being in URL-order (or document-order for POST parameters) would be highly convenient, but I'd like to know if I can actually *rely* on that behavior, or if I have to make arrangements to provide the ordering in a separate parameter. I'd like to know which specs mention these things if they are indeed specified in any of them. Thanks in advance, -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
