Tag Archives: JEE

Old Cool Dark Terminals

Posted on by
Reply

I have been working on JEE platform for 2 years as a professional. I like java and java related platforms but I really miss developing native applications on dark black linux terminals. I wish I have a chance to work on embedded devices as a professional. Nowadays being mobile is important as a result mobile devices are becoming more popular, most of these devices are based on linux firmwares. I recently discovered rockbox, it seems cool but I haven’t tested it yet. My iPod (nano classic) is a gift from one of my Apple fun friend, I don’t want to brake it. But somehow I feel I will find myself dealing with embedded platforms.

Dependency Injection Sucks

Posted on by
Reply

Java EE platform has many benefits one of them is Dependency Injection. It is an useful feature provides just using annotations instead of making lookups. However you cannot use it anywhere you like, only container managed components accepts resource injection. Such as EJB beans, Servlets, and JavaServer Pages (JSP) technology tag handlers. Thus, you can not use it in your helper classes and JPS pages. Why you cannot use it is;

JSP technology pages and tag files cannot accept resource injections either. Because such pages are usually compiled only after receiving a request, an annotation included in a JSP technology page would not be available to the container at deployment time when resource injection occurs.

Tag library validators (TLVs) and TagExtraInfo (TEI) are other classes that the JSP technology container manages, but because their life cycle is limited to the compilation of the JSP technology pages, they are not valid candidates for injection.

Supporting resource injection on JavaServer Faces technology renderers, converters, or validators is not desirable because that would violate Model-View-Controller (MVC) separation of these presentation objects. If these classes need to get access to resources, they should do so through a managed bean.

You cannot use this nice feature where it is most useful, it really sucks.

Ref : A Look at Resource Injection

Security in Java EE Part 1

Posted on by
Reply

Object Oriented application development provides developers to divide application into different layers such as database layer, business layer, presentation layer … etc. Multi layer application development approach provides easy to develop and maintain large scale projects. However, this approach addresses one of the most important issue, security.

Java EE consists of components ejb, web, web services, application clients … etc. Each of these components can be deployed into different containers or same container. Security is handled by the containers; a container provides programming or declarative security. Programming security is embedded control mechanism that is used when declarative security is insufficient. Declarative security defines applications security configuration out of the application via configuration files. Also, annotations define set of security rules by class files.

Java provides some security implementation mechanisms like;

  • JAAS: Java Authorization and Authentication Service consists of APIs to enable authorization and access control against to agents (user, account, service … )
  • Java GSS: Java Generic Security Services consists of APIs to enable securely exchange messages between applications.
  • JCE: Java Cryptography Extension provides framework implementations for encryption, key generation, key agreement and (MAC) Message Authentication Code algorithms.
  • JSSE: Java Secure Socket Extension provides implementation for a Java version of SSL and TLS protocols.
  • SASL: Simple Authentication and Security Layer a protocol for authentication and optional establishment of a security layer between client and server applications.

Reference:

http://java.sun.com/j2se/1.5.0/docs/guide/security/

http://java.sun.com/javase/technologies/security/

java.lang.OutOfMemoryError: PermGen space

Posted on by
Reply

If you are developing JEE applications with low resources (like me ) probably you have been facing “java.lang.OutOfMemoryError: PermGen space” exception and it will be your nightmare. Sample stack trace of exception:

StandardWrapperValve[Faces Servlet]: Servlet.service() for servlet Faces Servlet threw exception
java.lang.OutOfMemoryError: PermGen space
at sun.misc.Unsafe.defineClass(Native Method)
at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:45)
at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:381)
at java.security.AccessController.doPrivileged(Native Method)
at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:377)
at sun.reflect.MethodAccessorGenerator.generateMethod(MethodAccessorGenerator.java:59)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:28)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
…
…

You should add these parameters to domail.xml to get rid of this exception ( it is not exact solution) :

-Xmx256m
-Xms64m
-Xss128k
-XX:NewRatio=2
-XX:+CMSClassUnloadingEnabled
-XX:+CMSPermGenSweepingEnabled

Schema Generation : Hibernate vs Toplink

Posted on by
Reply

Do you know why I like hiberante and dislike toplink?
A simple reason should be hibernate scheme generation can update columns and lots of stuff in existing table as mentioned below:

SchemaExport (hbm2ddl): This tool is provided with the core Hibernate download. It uses Hibernate mapping metadata XML files to generate a SQL database schema with DDL. You can enhance your mapping files with database specific elements (SQL column datatypes, unique/check constraints/indexes, etc.) and then export the SQL DDL to a text file. You may also directly export the DDL to a database, this is very powerful in development, as you can automatically create and drop a database at each test run. See the Hibernate reference documentation for more information about this tool.

On the other hand, toplink can not update existing database table. It is terrible ….