anti-JSF thoughts

blog post moved to altuure.com

anti-JSF thoughts

Rapid Java : Part I (Platform)

For rapid and non-painful development and products here's some java libraries (startup dependencies)  I choose from bottom to top:

Module I: Core

• postgresql / mysql / hsql depends on project's size if you don't large size of startup data try to use hsql
• log4j : logging (alternative commons-logging)
• hibernate: Simple and high quality open source ORM (alternative:)
• springframework:  high quality IoC container and very good integration library (a framework to rule them all)
• quartz: scheduled task
• osworkflow: Simple workflow and state engine, to manage actions and states
  
• velocity: simple and useful template engine for formatted text/html/csv outputs (alternative freemarker)
• beanshell for providing business point (alternative groovy)
• acegi: Authentication and authorization
  

Module II : Report

• jfreechart:for impressive charts
• jasperreport: for pdf reports
• mondrian: for BI
• jxls: for excel reports

Module III: Web Layer

• Struts : here, you have lots of choice from popular jsf to tapestry,spring mvc, I choose struts because of two reason simple life cycle and it is action based current I am STILL using struts  1.2.x  but I will move to Struts2
  
• Prototype.js  standard js for web 2.0
• script.aculo.us very useful js lib for effects and more
• DWR for extra js calls from client browser to your java codes
• displaytag: very useful jsp taglib
• jstl: standard jsp taglib
• tomcat/jetty: choose one that you are familiar

It looks so complex at first sight and I'm sure it could be so painful to you but where All become one you would have quite clear Framework. 
for how to integrate them look at appfuse.

What is missing?
 your  application specs you can need JMS (eg: activemq)  ,networking (eg:jgroups) libs 

"Too many open files" but what are they?

java.io.FileNotFoundException: /opt/tb55/s3/conf/web.xml (Too many open files) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:106)

this shows the open file limit has been reached.. you can check this by JMX

java.lang:type=OperatingSystem >  OpenFileDescriptorCount

but what are these files ? you can see this by linux shell script

lsof -u tomcat

solution: increase systems open file limit !!!

vi /etc/security/limits.conf

and edit the line to increase open file limit

* soft nofile 3072
* hard nofile 4048

Clustering Acegi

Acegi is a well known security framework. Some really good features:

• method level based security configuration
• url level auth configuration
• easy login mechanism
• so on.

But there only one point that is missing in current version (1.0.3) distributable SessionRegistry, in fact there is one implemantion to this interface but it do not support multiple JVM.This is used for concurrent access with username.

Quick Fix:
replace the Maps in SessionRegistryImpl with your distributable caching mechanism (can be ehcache,oscache,vs) and reimplement it. Or you can use some JMS mechanism to fix this cap but it should be used only in complex architectures.

Acegi Concurrent Setup:

<bean id=" org.acegisecurity.concurrent.SessionRegistry" class="org.acegisecurity.concurrent.SessionRegistryImpl"/> <bean id="org.acegisecurity.concurrent.ConcurrentSessionController" class="org.acegisecurity.concurrent.ConcurrentSessionControllerImpl"> <property name="maximumSessions"> <value>1</value> </property> <property name="sessionRegistry"> <ref local="org.acegisecurity.concurrent.SessionRegistry"/> </property> <property name="sessionRegistry" ref="org.acegisecurity.concurrent.SessionRegistry"/> </bean> <bean id="org.acegisecurity.AuthenticationManager" class="org.acegisecurity.providers.ProviderManager "> <property name="providers"> <list> <ref local="org.acegisecurity.providers.dao.DaoAuthenticationProvider"/> <ref local="org.acegisecurity.providers.anonymous.AnonymousAuthenticationProvider"/> </list> </property> <property name="sessionController" ref="org.acegisecurity.concurrent.ConcurrentSessionController "/> </bean> <bean id="org.acegisecurity.concurrent.ConcurrentSessionFilter" class="org.acegisecurity.concurrent.ConcurrentSessionFilter "> <property name="sessionRegistry" ref="org.acegisecurity.concurrent.SessionRegistry"/> <property name="expiredUrl" value="/myself/"/> </bean>




And add org.acegisecurity.concurrent.ConcurrentSessionFilter to your filter list

PS:
check my new blog Clustering Acegi via JGroups (DistributedHashtable)

when do not generate code !

     Currently code generation is very common way of some handling common repeating code fragments and some initial setup task like startup configurations and so on. Some clear benefits are:

• ease your setup process
  
• protects your code form some common coding mistakes
  
• maintain some coding pattern practices and standards.
• keep your effort on complex tasks

But on the other hand when you evaluate code generator or while writing your code should thing about " why you generate this code ? and not writing some generic component to evolute such business"
 this is the most common mistake while using this technology. you generate code to customize the generated code. If you not need this fragment to customization. DO NOT GENERATE IT. otherwise in most case any enhancement in these fragments will require great effort or worse (to generate again).

so what is important.

• more less code generated more perfect it is
• more easily you customize it more useful it is

Some code generators:
http://www.codegeneration.net/

Who are you building for?

video

URI Encoding for tomcat 5.5.X

encoding problem with paramater while GET ?

for tomcat 5.5.x

http://split-s.blogspot.com/2005/12/internationalized-get-parameters-with.html

<Server ...> <Service ...> <Connector ... URIEncoding="UTF-8" /> ... </Connector> </Service> </Server>