Generally we can disable Client-initiated re-negotation in Jetty containers by setting the below property jetty.xml
<New id="ssl" class="org.eclipse.jetty.server.ssl.SslSelectChannelConnector">
<Set name="allowRenegotiate">FALSE</Set>
I would like to disable re-negotation in Spring boot embedded jetty. I checked below links but I didn't find any related property to implement this.
https://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html
https://github.com/spring-projects/spring-boot/blob/v1.5.4.RELEASE/spring-boot/src/main/java/org/springframework/boot/context/embedded/Ssl.java
Could someone please provide me some pointers to implement this. Appreciate your help.
Edited:
From the below link, I can see that by default allowRenegotiate is set to false. Is it is the same case with embedded Jetty?
https://wiki.eclipse.org/Jetty/Reference/SSL_Connectors
In regards to your question about embedded Jetty, allowRenegtionate is true by default; it is also on by default if you enable the ssl module in a current Jetty distribution.
I am unsure what version of Jetty you are using, but the wiki you linked to is for Jetty 7 and 8 which are both End of Life and no longer under active development. I strongly encourage you to upgrade to the latest release of Jetty, if possible, and to refer to current documentation as much has changed.
Related
With the new Intellij version (2022.3) Maven is no longer the default type (is has selected Bradle- Groovy) for a Java Project when using the spring boot initializr.
This is extremely annoying since Maven used to be the default option.
I have searched through all relevant settings I could come up with, without any luck.
Can anyone explain how to change the default settings for the spring intializr?
I also asked the question on IntelliJ support, and unfortunately this is not posible (yet)
As a consequence of my request, they have opened a feature request to allow for this:
https://youtrack.jetbrains.com/issue/IDEA-311387
If you, like me, are annoyed by this change please upvote the request
Each version has so different information that it is difficult to use.
I am using Spring Boot EhCache version 3.10.
Without a special Java configuration file, only the expiration time is entered in the xml file and then used.
Cache synchronization is required. So I found TerraCotta, but I can't quite figure out how to use it.
I checked the guide, but didn't understand which of these to use where and how.
I have received the TerraCotta server file, and I have run it, but please tell me how to configure SpringBoot to synchronize it.
I have this property into Spring Boot application:
server:
connection-timeout: 12000
I get warning:
Deprecated Each server behaves differently. Use server specific properties instead.
Gradle: org.springframework.boot:spring-boot-autoconfigure:2.6.8 (spring-boot-autoconfigure-2.6.8.jar)
is there some better configuration property that I can use?
I don't even know why you receive a deprecated warning.
According to the documentation from Spring Boot version 2.3 and onwards this property is removed not deprecated any more.
As you can read here, there are some other properties which you can use instead depending on the server that runs your spring boot application.
server.tomcat.connection-timeout should be used if you have tomcat as running server.
server.netty.connection-timeout should be used if netty is used.
server.jetty.connection-idle-timeout should be used if jetty is used
Basically each server has it's own implementation, so you must read your server's documentation to see what it allows and how this behaves. There might be slight differences from how one server behaves and how it interprets connection-timeout and how another server behave and interprets a similar configuration.
This is I think the reason that Spring decides to move to server specific configuration on property connection-timeout instead of a general property and also a very important reason was that some servers may not even have this configuration available to them. So then you have a general property configured in your spring boot application which the server that runs the application can't even respect.
Therefore you now have specific properties for specific servers and now you can be sure upfront whether this configuration is available in your server and you can also read the server documentation to understand exactly what the behavior will be.
Although this setting is being deprecated, we still can use the timeout function.
According to official document, we can use #Transactional(timeout = 1) to do the track in the controller
https://www.baeldung.com/spring-rest-timeout
We are using websphere application server 8.5 for our enterprise applications.
I want to know is there any integration testing framework other than arquillian?
I tried running with arquillian with embedded and remote. Because embedded does not provide support for CDI we don't want to use it. And with remote we are not able to start our tests because of some security issue. Even if we try to solve that we cannot use #PersistenceContext or #Resource etc.
So I would like to know if there is any integration testing framework exclusively for websphere.
Thank you
P.S.
I think I misunderstood #PersistenceContext and #Resource. Please correct me if I am wrong.
I can use #PersistenceContext or #Resource in my actual application but not in my arquillian classes. Am I right? Earlier I thought I cannot use these anywhere in my code.
Secondly, as a quick test, I tried disabling administration security on WAS and the test case ran successfully.
I want to know is there any integration testing framework other than arquillian?
Currently there are not any good Java EE test alternatives to Arquillian that I know of. However, you can make a decent test framework using some very basic ant scripting and junit.
(See this answer for testing in Java EE for an example implementation)
I think I misunderstood #PersistenceContext and #Resource. Please correct me if I am wrong.
I can use #PersistenceContext or #Resource in my actual application but not in my arquillian classes. Am I right? Earlier I thought I cannot use these anywhere in my code.
If you're going to use #PersistenceContext or #Resource in a class, that class should be container managed (i.e. deployed in an application as part of an ear/war/ejb module)
For future reference:
Secondly, as a quick test, I tried disabling administration security
on WAS and the test case ran successfully
For secured server you need to add username/password and ssl config. For further information look here.
Because embedded does not provide support for CDI we don't want to use
it.
That is actually not true. Embedded containers do support CDI and according to the arquillian blog CDI is one of the few reasons to use them... Update: On a 2nd look you are right as shown here. The blog is probably talking about all the other containers...
What is not supported by embedded containers?
Remote interfaces are not supported in the embeddable container.
In any way the above quoted article provides a good starting point when to use which container type.
I have ServiceMix installed behind a web proxy, and I need it to call a web service over the Internet.
I tried setting the proxy settings within my code with
System.setProperty("http.proxyHost" .....
(ugly and hacky, I know)
as well as setting the
http.proxyHost=myproxy
http.proxyPort=8080
http.proxyUser=myuser
http.proxyPassword=mypassword
in the etc/system.properties file of ServiceMix.
None of that worked.
Any suggestions would be appreciated.
Thank you.
Since your using ServiceMix you most likely are using Camel with CXF to call this webservice.
You need to set this proxy in your Camel context especially for CXF by setting the http-client configuration. Take a look at this link, it shows you how to configure the http conduit of CXF.
I'm sure your also able to set the proxy this way.
Use http:conduit:
<http:conduit name="*.http-conduit">
<http:authorization>
<sec:UserName>Betty</sec:UserName>
<sec:Password>password</sec:Password>
</http:authorization>
<http:client ProxyServer="x.x.x.x" ProxyServerPort="xxxx"/>
</http:conduit>
See: http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html