How can I turn off session persistence for geronimo? Is this something I should be doing? - I have no use for persisted sessions in my application. (This is because I recieve a not serializable error in my console, but I do not wish to serialize)
It depends upon which web container you're using within Geronimo; both Tomcat and Jetty are supported.
Tomcat
Add a context.xml file to your application or add these nodes:
<Context><Manager className="org.apache.catalina.session.StandardManager"
pathname=""></Manager></Context>
From the tomcat docs for pathname: Restart persistence may be disabled by setting this attribute to an empty string.
The properties are explained at these links:
https://cwiki.apache.org/GMOxDOC22/configuring-session-manager-of-tomcat.html
http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html#Standard_Implementation
Jetty
This container does not persist sessions by default, so there there is nothing to do except to make sure that the SessionHandler is not enabled. Remove the sessionHandler node if it exists in your context configuration.
<Set name="sessionHandler">
<New class="org.eclipse.jetty.servlet.SessionHandler">
<Arg>
<New class="org.eclipse.jetty.servlet.HashSessionManager">
<Set name="storeDirectory">your/chosen/directory/goes/here</Set>
</New>
</Arg>
</New></Set>
Informational link:
http://wiki.eclipse.org/Jetty/Howto/Persisting_Sessions
The solution for tomcat is depicted in http://www.unicon.net/node/608 and it works like a charm for us.
But I don't know if this also applies to geronimo since we are not using it.
Related
Having deployed the activemq-web-console war into a Tomcat embedded application how can one make it connect to an existing broker rather than create a new one?
The war comes with a set of predefined configurations, in particular, the WEB-INF/activemq.xml contains a configuration for the BrokerService
<broker brokerName="web-console" useJmx="true" xmlns="http://activemq.apache.org/schema/core">
<persistenceAdapter><kahaDB directory="target/kahadb"/></persistenceAdapter>
<transportConnectors>
<transportConnector uri="tcp://localhost:12345"/>
</transportConnectors>
</broker>
used from webconsole-embedded.xml in the following manner:
<bean id="brokerService" class="org.apache.activemq.xbean.BrokerFactoryBean">
<property name="config" value="/WEB-INF/activemq.xml"/>
</bean>
This configuration creates a new instance of BrokerService and tries to start the broker.
It is reported that the web console can be used to monitor an existing broker service rather than creating a new one. For this one should set the following properties somewhere:
webconsole.type=properties
webconsole.jms.url=tcp://localhost:61616
webconsole.jmx.url=service:jmx:rmi:///jndi/rmi://localhost:1099/karaf-trun
The questions is, where does one have to set these properties within the Tomcat embedded app and which XML changes in the above have to be performed for them to be used. I cannot find any sensible explanation how to configure it, and a BrokerService instance seems to be required by the remaining spring config.
Any ideas?
Please do not suggest to use hawtio instead!
I had the same problem today. You can start the webconsole in "properties" mode which gives you the oppertunity to connect over jmx.
I added following java arguments to our Jboss 6.1 and it worked immediatley. I didn't change any of the xmls (works out of the box)...
Example:
-Dwebconsole.type=properties -Dwebconsole.jms.url=tcp://<hostname>:61616 -Dwebconsole.jmx.url=service:jmx:rmi:///jndi/rmi://<hostname>:1090/jmxrmi -Dwebconsole.jmx.user=admin -Dwebconsole.jmx.password=123456
Also discussed here: https://svn.apache.org/repos/infra/websites/production/activemq/content/5.7.0/web-console.html
I'm trying to figure out the difference between this factories, used in hibernate.cache.region.factory_class property.
Example:
<property name="hibernate.cache.region.factory_class" value="org.hibernate.cache.infinispan.JndiInfinispanRegionFactory" />
<property name="hibernate.cache.infinispan.cachemanager" value="java:jboss/infinispan/container/hibernate" />
There are 4 possible options.
The 2 options that I know something about is:
org.hibernate.cache.infinispan.InfinispanRegionFactory: for standalone aplications (not in a cluster, I think).
org.hibernate.cache.infinispan.JndiInfinispanRegionFactory: this is bounded to a JNDI in the property hibernate.cache.infinispan.cachemanager.
And I don't have any idea about these 2:
org.jboss.as.jpa.hibernate5.infinispan.SharedInfinispanRegionFactory: ?
org.jboss.as.jpa.hibernate5.infinispan.InfinispanRegionFactory: ?
We have a cluster configured on Wildfly 10.1.0 using domain mode. We want to share the entity cache among the nodes and we are having some doubts about how to do that.
If you're using Wildfly, you don't have to worry about setting the region factory class because Wildfly uses Infinispan as second-level cache provider by default. It's all explained here.
All you have to do is enable hibernate.cache.use_second_level_cache and you're good to go. See examples in the docu.
I agree with Galder, +1!
Regarding the purpose of [org.jboss.as.jpa.hibernate5.infinispan.SharedInfinispanRegionFactory][1] + [org.jboss.as.jpa.hibernate5.infinispan.InfinispanRegionFactory][2], these classes extend the Hibernate ORM [hibernate-infinispan][3] implementation classes, the purpose being to start the internal WildFly Infinispan cache services used for the JPA second level caching. They also deal with configuration as well. The below links may become outdated over time, as I think we [3] code might move to the Infinispan project (eventually).
A little more of the related code is at [HibernateSecondLevelCache.java][4], which backs up what Galder said. You can see that the WildFly JPA container automatically is setting the region factory class for you (if caching is enabled via [HibernatePersistenceProviderAdaptor.java][5].
I'm not sure if the code links are helpful to you, I thought they might be. :)
As a stackoverflow newbie, I am not allowed to post with more than 2 links, which is why [3] - [5] are invalid links.
Scott
[1] https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/infinispan/SharedInfinispanRegionFactory.java
[2] https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/infinispan/InfinispanRegionFactory.java
[3] github.com/hibernate/hibernate-orm/tree/master/hibernate-infinispan
[4] github.com/wildfly/wildfly/blob/master/jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/HibernateSecondLevelCache.java
[5] github.com/wildfly/wildfly/blob/master/jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/HibernatePersistenceProviderAdaptor.java#L91
The configuration envolves Infinispan, Hibernate and JGroups.
Using domain-mode on Wildfly10 you'll need this configuration on your application EAR:
<property name="hibernate.cache.use_second_level_cache" value="true"/>
Your server group need to use a profile that has the ha resources(high availability) such as full-ha or ha profiles. These profiles have the Infinispan and JGroups default configuration.
Then, you need to have the private 'Network Interfaces' on ALL Hosts' configuration that share the cache. JGroups uses the private Edit the domain/configuration/host.xml or use the wildfly console admin to add this configuration (200.0.0.171 needs to be replaced by the server's IP):
<interfaces>
...
<interface name="private">
<inet-address value="${jboss.bind.address.private:200.0.0.171}"/>
</interface>
<!-- .... -->
</interfaces>
For example, supposing you have a HostController HC1(with server-1 and server-2) and HC2(with server-3 and server-4)
Starting all the servers and Host Controllers, you'll see on your server.log:
INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000078: Starting JGroups channel hibernate
....
....
Received new cluster view for channel hibernate: [HC1:server-1, HC2-server-2, HC2-server-3, HC2-server-4]
I am running a Spring Boot application in AWS. The application is running behind an Elastic Load Balancer (ELB). The ELB is configured to use https (port 443) to the outside world, but passes through http (port 8080) to the application. The ELB is configured to pass through the x-forwarded-proto header. I am using Jetty 9.0.0.M0, with Spring Boot 1.1.5 RELEASE.
I appear to be getting incorrect redirects sent back from the application via the ELB where the redirect responses are coming back as http, rather than https. Now, I read here that I should set the "forwarded" header to true using:
<Set name="forwarded">true</Set>
I can't see how to do this with the embedded version of Jetty in Spring Boot because there is no XML configuration file as part of my source.
I have looked at the EmbeddedServletContainerCustomizer infrastructure but I still can't get the right incantation to get this setup to work.
The application is built and tested outside of the AWS https environment, so the application needs to transparently work with http too. Directly hitting the application endpoints without going through the ELB works. It's just that the ELB to application route that's not working.
Any ideas?
Had a similar issue myself and while researching stumbled across your question. I found this was quite easy to to programatically however isn't really explained in the Jetty docs.
The structure of the Jetty xml configuration files are matched by the structure of the java API so you can just replicate it in code.
So following the Jetty guide on how to configure using the XML configuration file here
I was able to configure the embedded server programatically like this:
Server server = new Server( port );
// Create HTTP Config
HttpConfiguration httpConfig = new HttpConfiguration();
// Add support for X-Forwarded headers
httpConfig.addCustomizer( new org.eclipse.jetty.server.ForwardedRequestCustomizer() );
// Create the http connector
HttpConnectionFactory connectionFactory = new HttpConnectionFactory( httpConfig );
ServerConnector connector = new ServerConnector(server, connectionFactory);
// Make sure you set the port on the connector, the port in the Server constructor is overridden by the new connector
connector.setPort( port );
// Add the connector to the server
server.setConnectors( new ServerConnector[] { connector } );
Try setting the following property in your spring boot application:
server.use-forward-headers=true
The will ensure the correct protocol is read from the header. Refer to documentation here:
https://docs.spring.io/spring-boot/docs/1.5.9.RELEASE/reference/html/howto-embedded-servlet-containers.html
I found a couple problems with the default Spring Boot Jetty configuration, not the least of which are enabled SSL algorithms which SSLLabs Check doesn't like.
Anyway: The fix I found for this was something like:
#Bean
public JettyEmbeddedServletContainerFactory jettyEmbeddedServletContainerFactory()
{
// Deploy the nuclear option, kill the default Spring Boot factory
// and replace with mine that disables extra crud.
JettyEmbeddedServletContainerFactory fac = new JettyEmbeddedServletContainerFactory();
// This allows ELB to work.
fac.setUseForwardHeaders( true );
return fac;
}
There are also a number of other ELB options that you need to setup if you want SSL end-to-end. I had to use the command line client with some tweaks and change the health checks to TCP:8443 b/c the EC2 instance certificates look invalid to the load balancer.
Here's what just worked for us with a Spring app behind jetty-runner-9.3.6.jar. In our case, our jetty.xml didn't have any addConnector already, and trying to add just the addConnector would error out.
Found it here - https://github.com/george-hawkins/authsite/blob/2c5d61b984a328ef878216a3acfd0ad2593f81b1/src/main/config/etc/jetty.xml
<New id="httpConfig" class="org.eclipse.jetty.server.HttpConfiguration">
<Call name="addCustomizer">
<Arg><New class="org.eclipse.jetty.server.ForwardedRequestCustomizer"/></Arg>
</Call>
</New>
<Call name="addConnector">
<Arg>
<New class="org.eclipse.jetty.server.ServerConnector">
<Arg name="server"><Ref refid="Server" /></Arg>
<Arg name="factories">
<Array type="org.eclipse.jetty.server.ConnectionFactory">
<Item>
<New class="org.eclipse.jetty.server.HttpConnectionFactory">
<Arg name="config"><Ref refid="httpConfig" /></Arg>
</New>
</Item>
</Array>
</Arg>
<Set name="port"><SystemProperty name="jetty.port" default="8080"/></Set>
</New>
</Arg>
</Call>
What this DOES is to modify the Request object that is passed through to make it -look- like it didn't come through a proxy (replacing the details with whatever X-Forwarded headers are available and supported).
See http://archive.eclipse.org/jetty/9.0.0.M4/apidocs/index.html?org/eclipse/jetty/server/ForwardedRequestCustomizer.html
This customizer looks at at HTTP request for headers that indicate it has been forwarded by one or more proxies. Specifically handled are:
X-Forwarded-Host
X-Forwarded-Server
X-Forwarded-For
X-Forwarded-Proto
If these headers are present, then the Request object is updated so that the proxy is not seen as the other end point of the connection on which the request came
I have been unable to find a simple Jetty 9 solution to this question. Other than recommending that I upgrade to a later version of Jetty (which is good advice) I have received no other suggestions (at this time, as you can see)
My solution for the sake of expedience is to abandon Jetty, and instead to use embedded tomcat, where this functionality is a simple matter of configuration in the application.properties file. Simply add the following line to application.properties:
server.tomcat.remote_ip_header=x-forwarded-for
This appears to do the trick using the default embedded tomcat that comes as part of Spring Boot.
I have configured Tomcat 6 with in-memory session replication. I am also using IIS 7 (I know, I know) and the AJP connector via isapi_redirector. The cluster is working properly and I am able to replicate session attributes using the SessionExample in the examples war. The problem is that I am unable to do the same in my custom application. I have added the distributable tag to the web.xml file on both servers in my test cluster. However, I don't see any message in the logs mentioning the attributes getting sent to the cluster (I see them for SessionExample). The only primary differences that I can see in my app from the examples:
The examples war uses servlet 2.5. I am still required to use 2.4.
My application uses SSO and requires the user to login.
The application is a portal application.
Also, in the code of the application, I am setting a simple string in the attribute, so nothing fancy.
So, I was wondering if anyone has some tips to get this working?
Thanks
Here is the cluster section within of my server.xml:
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="6">
<Manager className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.McastService"
address="228.0.0.104"
port="45564"
frequency="500"
dropTime="10000"/>
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="auto"
port="4000"
autoBind="100"
selectorTimeout="7000"
maxThreads="6"
timeout="15000"/>
<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"
timeout="70000"/>
</Sender>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
</Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;"/>
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
<Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/apache-tomcat-6.0.37/war-deploy/war-temp/"
deployDir="/apache-tomcat-6.0.37/webapps/"
watchDir="/apache-tomcat-6.0.37/war-deploy/war-listen/"
watchEnabled="true"/>
<ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
Sorry. I found the issue. I was expecting to see messages in the log regarding the creation of the session attributes. I didn't realize that the examples project had a session listener that was outputting the messages to the log. I was thinking that it was simply from the log level that I had set.
Thanks to anyone who read this post.
I use Spring to configure my Java Web App and in my Spring configuration I obtain a datasource via JNDI for Jetty as follows:
<jee:jndi-lookup id="dataSource" jndi-name="jdbc/myDataSource" />
but this won't work with Tomcat. With Tomcat I have to do this:
<jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/myDataSource" />
Whats the best way to solve this? I am already using JNDI as a way to externalize configuration, so I can't externalize my externalized configuration! At the same time I absolutely loath the idea of having two separate Spring configuration files. HELP!!!
I found an answer here, but I thought it was a bit complicated, but it did give me the idea to use the very cool ServerDetector class that blogger had found.
Once I can dynamically figure what type of server I am running in, I was able to use the Spring expression language to do the rest of the work:
<jee:jndi-lookup id="myAppDataSource"
jndi-name="#{ (AppServerType == 'Jetty' ? 'jdbc/' : 'java:comp/env/jdbc/') +
'myAppDataSource' }" />
Easy!
After some experimenting, I figured out I could just force Jetty to use the same JNDI path as Tomcat. The following snippet is from my jetty-env.xml file:
<New id="myDataSource" class="org.mortbay.jetty.plus.naming.Resource">
<!-- We MUST specify the entire JNDI path here to force compliance with the Tomcat/J2EE convention -->
<Arg>java:comp/env/jdbc/myDataSource</Arg>
<Arg>
<New class="com.atomikos.jdbc.nonxa.AtomikosNonXADataSourceBean">
<Set name="uniqueResourceName">sbeDatabase</Set>
...............
</New>
</Arg>
</New>
Not sure if this is ideal, but it works.
Update:
It works if you put your jetty-env.xml file inside the WAR...but for whatever reason, one you move this configuration outside the WAR and into a context fragment file in Jetty's "contexts" directory then it throws an exception:
Check it out: http://jira.codehaus.org/browse/JETTY-273
The cleanest way to do it is to configure your configuration. ;)
Use a Spring property place holder. See
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-factory-placeholderconfigurer
The basic idea is that you just put a placeholder in your spring config with a property, and then it reads matching property from a properties file. You generate the properties file in your build process. Ive seen it done where the build tool (ant) reads an environment variable and then creates a properties file appropriate for the environment based of a skeleton file populated with tokens.