Re: Ready for JDK 9 ?
I apologize, maybe I am off-topic but I can't find any resource on my problem. Java Web Applications will be loaded by some custom classloader provided by the container, so they will be treated as unnamed modules or there is some standard mechanism to load the WEB-INF/classes directory as part of a module? I will appreciate any pointer Enrico Il mar 8 ago 2017, 11:30 Rory O'Donnell ha scritto: > > Hi Mark, > > Thank you very much for all your testing of JDK 9 during its > development! Such contributions have significantly helped shape and > improve JDK 9. > > Now that we have reached the JDK 9 Final Release Candidate phase [1] , I > would like to ask if your project can be considered to be 'ready for JDK > 9', or if there are any remaining show stopper issues which you've > encountered when testing with the JDK 9 release candidate. > > JDK 9 b181 is available at http://jdk.java.net/9/ > > If you have a public web page, mailing list post, or even a tweet > announcing you project's readiness for JDK 9, I'd love to add the URL to > the upcoming JDK 9 readiness page on the Quality Outreach wiki. > > > Looking forward to hearing from you, > Rory > > [1] http://openjdk.java.net/projects/jdk9/ > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- -- Enrico Olivelli
Re: Default character encoding to be UTF-8 for 9.0.x
My two cents... It would be great! The backport to 8.5 too I always need to add some filter or some lines of code to every servlet. Enrico Il mer 1 mar 2017, 14:31 Mark Thomas ha scritto: > Servlet 4.0 adds the ability to set a default request character encoding > and a default response character encoding in web.xml and > programmatically. The spec allows containers to specify their own > defaults via vendor specific config. We can do this via conf/web.xml. > > Therefore, I would like to propose we configure, via conf/web.xml, UTF-8 > as the default request and default response character encoding. > > Thoughts, comments and/or objections? > > Mark > > P.S. Because of the way this is implemented, we could do something > similar with 8.5.x as well via conf/context.xml > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- -- Enrico Olivelli
Re: java-server-socket-binding-multiple-domain-host-names
If you are using HTTP then clients will politely tell you which DNS name they are tryning to connect to using the "host:" header. TCP does not give any info about "hostnames", but only about "IP Addresses" I think .getLocalAddress().getHostName() will simply try to resolve back the IP address to a DNS name I hope that helps Enrico Il 25/05/2013 18:23, Elgs Chen ha scritto: Hi Mark, I'm very sorry I know this is not related to the Tomcat project. However, I cannot find anyone who I think has more expertise in java networking programming than you. I have a java server socket problem and I have no way to find the answer. I'm really hoping I can get some insights from you. Thanks in advance. And here's the URL to this question: http://stackoverflow.com/questions/16751062/java-server-socket-binding-multiple-domain-host-names I have a java nio server with ip address 192.168.0.1 listening on port 80. I configured this server to bind to multiple domain/host names, let's say server1, server2, server3 are all resolved as 192.168.0.1. Now I'm hoping if the client connects to server1, on the server side, I can recognize that the client is connecting to server1 instead of other names or direct ip address, so that I can do something special, and if the client is connecting to server2, I can recognize that the client is requesting server2, so I can do something else special, and so on. Now the question is: seems on the server side, I cannot easily get the correct information which server name my clients are connecting to. I have the follow code: ServerSocketChannel ssChannel = (ServerSocketChannel) selKey.channel(); String boundHost = sChannel.socket().getLocalAddress().getHostName(); But it does not work, the boundHost is always the server1 even if clients connect to server2 or server3. Thanks, Elgs - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-181) Allow to run the webapp under the root context
[ https://issues.apache.org/jira/browse/MTOMCAT-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13478045#comment-13478045 ] Enrico Olivelli commented on MTOMCAT-181: - please implement this, in this way I will be able to use tomcat plugin for integration testing > Allow to run the webapp under the root context > -- > > Key: MTOMCAT-181 > URL: https://issues.apache.org/jira/browse/MTOMCAT-181 > Project: Apache Tomcat Maven Plugin > Issue Type: New Feature > Components: tomcat7 >Reporter: Sergio Fernández >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Minor > Fix For: 2.1 > > > Right now the plugin simply ignores this: > > org.apache.tomcat.maven > tomcat7-maven-plugin > 2.0 > > / > > > and take the artifactId as default context path. > Would be possible to run it under the root context? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Request for JAASRealm enhancement
Hi, I was trying to use JAASRealm and I noticed that it is possibile to bundle my LoginModule with the webapp (useContextClassLoader) but it is not possibile to bundle a login.properties files // this constructor uses default JVM JAAS Configuration // from JAASRealm.java loginContext = new LoginContext(appName, callbackHandler); // the constructor I would like to be used URI = URI that gets a .properties file thru the classloader of my app ConfigFile file = new ConfigFile(URI); loginContext = new LoginContext(appName, callbackHandler,...,ConfigFile); can you add a configuration property for that realm in order to configure a JAAS ConfigFile ? in this way I can bundle my login.properties file inside the app or in some JAR to be distributed Thank you - Enrico - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
