We had a pretty old server Ubuntu server with GlassFish 2.1.1 running. At some point we decided to move it to a more recent OS version. Being a long time Fedora user and a sort Red Hat fan boy in general – CentOS on EC2 was a pretty straightforward choice for me. Moving there was not trivial but finally I got things running in the manner I really want and would like to highlight some problems you might come across….
I like spring framework – it is very flexible and provides a lot of useful mechanisms, but sometimes configuration of spring-base project is very annoying. On one our project we mix xml-based configuration with annotation-based configuration. The rule is very simple for this: use annotations and if you need additional flexibility then use xml. Also we use xml for configuration standard mechanisms, e.g. transactions, security, acl, etc. Unfortunately this simple approach doesn’t work correctly for all cases. 🙁 I found…
Recently we moved our server from Postgresql 8.3 to Postgresql 8.4, and I faced with a problem with some functionality mulfunction. In glassfish domain log I found errors that transaction could not be rolled back during postinvoke on bean. The problem was found out when I went to the logs of PostgreSQL: 2010-09-09 17:19:09 EEST ERROR: prepared transactions are disabled2010-09-09 17:19:09 EEST HINT: Set max_prepared_transactions to a nonzero value. And really, in Postgresql 8.4 the max_prepared_transactions parameter became 0, meanwhile…
I think all Java-developers know JNDI (Java Naming and Directory Interface) and all of them use it. The common case of its use is getting datasource and getting JMS queue. In this post I’d discuss usage of JNDI for custom objects. On one of our project we need to have access to one common knowledge base, which should be shared between several application deployed on this application server (it was glassfish v3, but it doesn’t matter). Thus our application is…
There are two major problems with installing glassfish through puppet in default configuration of puppetmaster: * The jar file of glassfish is too big * You have to accept sun lisense during the installation The cause of first problem is that by default puppetmasterd uses WEBRICK as it web-server. It would be probably not a problem if it was not using at the same time xmlrpc calls. The consequence of such configuration is that big files timeouts to be transfered….
By default magnolia-cms is working on Tomcat, but it is easy to run it on Glassfish v2. You only need to deploy magnolia in glassfish and after that add default JAAS login configuration into login.conf, which is place in conf directory of your domain:
Also check that “Default Principal To Role Mapping” flag is not checked for your domain (you’ll find it on Configuration -> Security page of glassfish Admin Console).